تقریباً دقیقاً یک سال پیش ، من یک پست وبلاگ منتشر کردم که دارای جزئیات زیادی بود ، چرا در آن زمان ActivityPub را برای اجرای به عنوان لایه فدراسیون پایه در دیاسپورا مناسب نمی دانم. طی سال گذشته ، چندین درخواست برای پیگیری دریافت کرده ام. متأسفانه ، نظر من امروز نیز ادامه دارد ، اما پس از مدتی بررسی ، من فكر كردم كه باید پیگیری كنم ، با برخی یادداشت های اضافی و چیزهایی كه در آن مدت آموخته ام.
مقدمه
قبل از ادامه در اینجا ، من می خواهم ابتدا دو مقاله دیگر را توصیه کنم. این قطعه توسط نویسنده همكاری ActivityPub ، كریستوفر وبر ، مشكلات كار در این گروه كاری را توضیح می دهد و جزئیات زیادی راجع به انتظارات متفاوت و تلاش برای گردهم آوردن همه را بیان می كند. همچنین ، این قطعه توسط نویسنده Friendica ، مایکل وگل ، وجود دارد که مشکلاتی را که هنگام افزودن پشتیبانی ActivityPub با آنها روبرو شده اند ، و نحوه تلاش آنها برای رفع این مشکلات را توضیح می دهد.
همانطور که احتمالاً می توانید از عنوان استخراج کنید ، این مقاله بیش از حد احتمالاً مقاله من خواهد بود قطعه نهایی ActivityPub ، و من در واقع این بار حتی به جزئیات فنی نمی پردازم. هدف من این است که از این به عنوان یک قطعه مرجع استفاده کنم تا در صورت بروز سوال به آن اشاره کنم. در این مرحله ، همه در حال چرخش در محافل هستند و من احساس نمی کنم که ما واقعاً بتوانیم پیشرفت کنیم. من دلیل آن را کمی بعد در این پست توضیح خواهم داد.
ActivityPub چیست
یکی از متداول ترین سو [تفاهمات درباره در مورد ActivityPub که می بینم از س questionال بسیار ساده این است که ActivityPub چیست ، و آنچه SocialWG می خواست آن باشد. برای پاسخ دادن به آن ، ما باید با مراجعه به منشور گروه کاری وب اجتماعی ، که اساساً سندی است که اهداف آن گروه کاری را توصیف می کند:
یک نحو مشترک مبتنی بر JSON برای داده های اجتماعی ، یک API سمت مشتری و یک پروتکل وب برای فدراسیون اطلاعات اجتماعی
بنابراین اساساً آنها می خواهند دو چیز ایجاد کنند:
- پروتکل مورد استفاده برای تبادل چیزهای بین سرورها و همچنین بین سرورها و مشتری ها و
- یک نحو JSON'y برای نمایش داده های اجتماعی
بیایید برجسته ترین نتایج آنها را بررسی کنیم.
ActivityPub
ActivityPub "پروتکل وب برای فدراسیون اطلاعات اجتماعی" بخشی از معادله است ، اما همچنین مسئول تعامل مشتری با سرور است. ActivityPub یک پروتکل فدراسیون شبکه اجتماعی کامل نیست. این پروتکل حمل و نقل برای انتقال چیزها بین سرورها و سرویس گیرندگان است.
اگر با اصطلاحات وب زیاد آشنا نیستید ، به ActivityPub به عنوان سرویس پستی فکر کنید. سرویس پستی به اطراف می چرخد و نامه ها را به صندوق های تحویل می دهد ، اما به آنچه در واقع درون آن نامه ها است اهمیت نمی دهد. این یک تشبیه کامل نیست ، بلکه به اندازه کافی نزدیک است.
جریان های فعالیت
جریان های فعالیت "نحو مبتنی بر JSON برای داده های اجتماعی" است که گروه کاری می خواست طراحی کند. جریان های فعالیت چیزی نیست که SocialWG مستقیماً اختراع کرده باشد. از سال 2011 ، جایی که نسخه اول آن منتشر شد ، همچنان ادامه دارد. SocialWG از Activity Streams 1.0 به عنوان پایه استفاده کرد ، بعضی قسمتها را اصلاح کرد ، بعضی قسمتهای دیگر را اضافه کرد و نتیجه را به عنوان Activity Streams 2.0 منتشر کرد.
برای درک اینکه Activity Stream ها چیست ، فکر کنید که این یک نحو انتزاعی است تا اساساً هر چیزی را نشان دهد می تواند یک اقدام در در شبکه های اجتماعی باشد. مشخصات واژگان جریان های فعالیت ، در میان سایر موارد ، سه نوع اشیا را تعریف می کند:
-
بازیگران :
برنامه
،گروه
،سازمان
،شخص
،خدمات
. - ]
انواع فعالیت ها :پذیرش
،افزودن
،اعلام
،ورود
،بلوك
،ایجاد
،حذف
،دوست نداشتن
،پرچم
،دنبال كن
،نادیده بگیر
، دعوت ،عضویت
،ترک
،مانند
،گوش دادن
،حرکت
،پیشنهاد
،س [ال
،بخوان
،رد
،حذف
حذف ،پذیرش آزمایشی
،رد مشروح
،
سفر
،واگرد
،بروزرسانی
،مشاهده
. -
اشیا [:
مقاله
،صوتی
،سند
،رویداد
،تصویر
،] یادداشت
،صفحه
،مکان
،مشخصات
،رابطه
،سنگ قبر
،ویدئو
.
برای ایجاد یک فعالیت معتبر جریان فعالیت ، یکی از هر دسته را انتخاب می کنید و چند فراداده به آن اضافه می کنید. شما توصیف می کنید که کاری کاری به چیزی یا با آن انجام داده است ، و آن چیزها را با جزئیات بیشتری توضیح می دهید.
این مفهوم خیلی باحال. اگر لیست انواع اشیا کامل باشد (یا قابل تمدید باشد) ، می توانید هر آنچه را که نیاز دارید با آن نشان دهید. بنابراین ، به گروه کاری برای رسیدن به هدف خود در اینجا احترام بگذارید.
آنچه که نیست
اکنون که ما یک مبنای اساسی در مورد ActivityPub ایجاد کردیم ، باید در مورد موضوع بحث برانگیز صحبت کنیم. درباره چیزهایی که ActivityPub نیست نیست. همه موافقند که ActivityPub و مشخصات خواهر آن یک چارچوب عالی برای ایجاد تعاملات شبکه های اجتماعی فدرال هستند. با این حال ، من مشکل دارم که آن را به عنوان یک پروتکل واقعی برای پیاده سازی در شبکه های اجتماعی برای ایجاد کانال های ارتباطی قابل اعتماد در نظر بگیرم.
من این موضوع را در آخرین پست خود به تفصیل توضیح داده ام ، و دیگر تکرار نمی کنم خودم اینجا با این حال ، به طور خلاصه ، تعداد بسیاری از اتاق تکان دادن در مشخصات وجود دارد. به عنوان مثال ، مشخص نیست که آیا ویژگی های لازم برای نوع شی وجود دارد یا خیر ، کدام یک از این ویژگی ها وجود دارد. فعالیتهای جریان همچنین توضیح می دهد که می توان آن را به هر روشی که تصور شود قابل تمدید است ، و اساساً هیچ محدودیتی ندارد:
[…] "توسعه" هر نوع ویژگی ، فعالیت ، بازیگر یا شی object است که توسط واژگان فعالیت تعریف نشده است. با استفاده از پیاده سازی ها […] باید پردازش موارد را به گونه ای ادامه دهید که گویا این ویژگی ها وجود نداشته باشد.
با این مقدار قابلیت گسترش دقیق در مشخصات ، دیگر نیازی به پرسش نیست که آیا این یک اشکال است یا یک ویژگی. این یک ویژگی است و حتی بخشی از منشور گروه کاری بود. این خوب است ، اگر ActivityPub را به عنوان یک چارچوب ببینیم ، اما به نظر اکثر افراد ، به نظر می رسد ActivityPub چیز دیگری است.
فقدان قابلیت همکاری از طریق طراحی
من تصدیق می کنم که این کمی جزئی است تیتر خشن ، و این همان چیزی نیست که مشخصات آن در نظر گرفته شده است ، اما همان جایی است که اکنون پیاده سازی ها انجام می شود.
وقتی توصیه ActivityPub منتشر شد ، هیجان زیادی را به دنبال داشت. کاملاً شایسته ، زیرا همانطور که قبلاً اشاره کردم ، احساس می کنم یک بستر عالی برای ساختن چیزهایی در بالای آن است. با این حال ، احساس می کنم این هیاهوی تبلیغاتی جایی است که همه چیز در جایی اشتباه تغییر کرده است. پروژه ها شروع به استفاده از مارک ActivityPub به عنوان نمادی برای کانالهای ارتباطی فوری و تضمین شده ، در آن سوی مرزها کردند. آنها در اینترنت گشت و گذار کردند و به پروژه هایی گفتند که ActivityPub را برای پیوستن به فدراسیون جهانی پیاده سازی کنند و آنها ادعا کردند که فقط با افزودن پشتیبانی ActivityPub ، کاربران می توانند با یکدیگر ارتباط برقرار کنند.
من خیلی زود ، من مطرح کردم نگرانی در مورد قابلیت همکاری واقعی ، ادعا کردن بسیاری از مشخصات بسیار مبهم است یا به سادگی تعریف نشده است ، زیرا این مشخصات می تواند منبع منطقی حقیقت هنگام اجرای یک شبکه اجتماعی باشد. نکته ای که در آن من شروع به پرسیدن پروژه ها و مجریان در مورد برنامه هایشان برای اطمینان از قطع شدن کار کردم ، همه چیز جالب شد. من توانستم بحثهای بسیار خوبی با افرادی که قسمتهای مختلف مشخصات را نوشتند و یا افرادی كه از طرق دیگر در جاهایی مانند کانال IRC SocialWG درگیر بودند ، داشته باشم و همچنین با افرادی كه در مشخصات دیگر در جاهایی مانند كانالهای IndieWeb مشاركت دارند بحثهای جالبی داشتم .
با کمال تعجب ، این افراد هرگز کاملاً با نظرات من مخالف نبودند. حتی افرادی که در ActivityPub و Activity Stream ها مشارکت داشتند موافق بودند که در این ادعاها اعتبار وجود دارد و در حالی که هیچ کس فکر نکرده است که ActivityPub مرده است (حتی من ، همانطور که اکنون می توانید بگویید) ) ، مردم توافق کردند که اینها نکات مهمی برای بحث و گفتگو هستند.
حدس بزنید چه کسی با من موافق نیست؟ گروه جدید الانتشارهای ActivityPub و برخی از مجریان. این افراد ادعا می كنند كه توضیحات من شنیع است ، و اینكه "19459006]" موانع "من اظهارات مبهمی است ، اما هنوز مدیون واقعی آن (و همه افراد دیگر) به من مدیون است.
ایدئولوژی نسبت به کاربران
متأسفانه ، این الگویی است که ما می توانیم آن را اغلب بخصوص در هاردکور هاردکور دنیای نرم افزار منبع باز و آزاد مشاهده کنیم. در واقع کاملاً معمول است که افراد آنجا ایدئولوژی خود را بر اساس نیازهای واقعی کاربر قرار می دهند و این موضوع من را بسیار ناراحت می کند.
من همیشه سعی می کردم کاملاً روشن کنم که فقدان قابلیت همکاری مشخص خطرناک است. نه برای افرادی که آن را اجرا می کنند ، بلکه برای مردم است که از استفاده می کنند. در واقع ، نکته ای که من در مورد پروژه های اجرای ActivityPub بیشتر از همه نگران آن هستم.
در یک نظر اخیر GitHub ، من استفاده از کلمه ActivityPub را به عنوان برچسبی برای سیلی زدن به چیزها زیر سال بردم ، زیرا من می ترسم این باعث گیج شدن کاربران شود. به نظر من ، ما باید در حال ایجاد راه حل هایی باشیم که مورد توجه توده هایی که هنوز از شبکه های بزرگ و متمرکز استفاده می کنند ، باشد. اگر فقط فقط در حبابی بمانیم که درباره پروتکل ها و مسائل قابلیت همکاری درک می کند ، هیچ رشد برای ما وجود ندارد. علاوه بر این ، گرچه من دیاسپورا را به عنوان "چیز بزرگ جدید" نمی بینم ، من دوست دارم در جهانی زندگی کنم که همه شبکه های اجتماعی توزیع شده "چیز بزرگ جدید" باشد. در یکی از تصمیمات اخیر ، پس از مواجه شدن با این جمله که به نظر می رسد پیاده سازی ها ActivityPub را به عنوان گلوله جادویی برای حل همه مسائل بین برابری ستایش می کنند ، یک مجری ادعا کرد:
شک دارم کسی که تاکنون به ActivityPub نگاه کرده باشد ، فکر می کند هر چیزی که از ActivityPub پشتیبانی می کند باید به طور خودکار با تمام پیاده سازی های دیگر سازگار باشد. این واقع بینانه نیست. من هیچ عملی با این ادعا نمی دانم و هرگز چنین عملی وجود نخواهد داشت.
این یكی از ادعاهایی بود كه مرا مبهوت كرد زیرا من به یك واقعیت می دانستم كه این موضوع خیلی خلاف واقع است. بررسی سریع واقعیت در مورد انتظارات مطرح شده توسط مردم و پروژه های این زمینه:
- Christopher Webber در وبلاگ رسمی FSF: "من موافقت كردم كه می خواهیم اطمینان حاصل كنیم كه هر API فدراسیون استفاده می كنیم به طور گسترده ای با سایر برنامه ها سازگار است. وب سایت های شبکه های اجتماعی رایگان که ممکن است "
- وبلاگ رسمی NextCloud در مورد پشتیبانی جدیدشان از ActivityPub: "با استفاده از استاندارد محبوب ActivityPub ، کاربران Nextcloud می توانند در به اصطلاح" fediverse "، یک شبکه بهم پیوسته و غیرمتمرکز ، به روزرسانی وضعیت را مشترک شوند و با آنها به اشتراک بگذارند از سرورهای مستقلاً اداره شده! "
- وبلاگ رسمی Mastodon درباره افکار آنها درباره آینده: "شبکه اجتماعی که Mastodon است در واقع Mastodon نیست. بزرگتر است هر نرم افزاری است که ActivityPub را پیاده سازی می کند. […] همه این سیستم عامل ها متفاوت هستند و بر نیازهای مختلف متمرکز هستند. و با این وجود ، بنیاد یکسان است: افرادی که برای دریافت پست از افراد دیگر مشترک می شوند. بنابراین ، همه آنها سازگار هستند. "
جمله ای که در آن اطلاعیه ها به کار رفته است برای درک من کاملاً واضح است.
قرار دادن آرم ActivityPub در وب سایت یک پروژه و نوشتن پست های اعلامیه" ما از ActivityPub پشتیبانی می کنیم "، افراد کاملاً فنی را کاملاً آشنا می کند خوشحال ، و افرادی که از استانداردهای باز پشتیبانی می کنند آنها را با چشمانی درخشان می خوانند. با این حال ، یک اثر ثانویه وجود دارد: این اطلاعیه ها چیزی را به کاربران غیر فنی نیز منتقل می کند. این به کاربران می گوید که این نرم افزار با سایر نرم افزارهایی که دارای همان آرم هستند سازگار است. اما اینطور نیست. در بحث اخیر دیگری ، وقتی کسی از من س askedال کرد که چرا دیاسپورا هنوز از ActivityPub پشتیبانی نمی کند ، من ادعا کردم که این پروژه در اینجا دو گزینه دارد ، که تأثیر مستقیمی بر چگونگی توضیح سازگاری با کاربران در شبکه های دیگر دارد:
- متأسفم ، آلیس ، باب از نرم افزاری استفاده می کند که با ما سازگار نیست ، بنابراین شما نمی توانید با باب در اینجا ارتباط برقرار کنید.
- بله ، می توانید با باب ارتباط برقرار کنید ، اما از آنجا که او از ExampleNet استفاده می کند ، لطفاً توجه داشته باشید که باب شما را دریافت نمی کند آلبوم های عکس و نمی توانند با آنها تعامل داشته باشند. کارول عکس های شما را می بیند ، اما متأسفانه ، او نمی تواند به روزرسانی های موقعیت مکانی شما را ببیند. علاوه بر این ، به دلیل محدودیت های فنی ، دان می تواند در مورد پست های شما نظر دهد ، اما ما نمی توانیم اطمینان حاصل كنیم كه كارول و باب این موارد را می بینند ، زیرا ما نمی توانیم نظرات دان را توزیع مجدد كنیم.
من از یک نفر خواستم که در آن بحث از ActivityPub به شدت دفاع کند تا به من بگوید چه چیزی آنها ترجیح می دهند ، اما جوابی ندادند. نقل قول از شخصی که روی یک پیاده سازی ActivityPub کار می کند و به طور فعال پروژه های دیگر را مجبور به انجام این کار می کند ، با مواجه شدن با وضعیت فوق:
بله ، ActivityPub به معنای "یک تجربه کاربر ناسازگار" است. این بخشی از معامله است. اگر آن را قبول ندارید - یک سیستم عامل فدراسیون ایجاد نکنید. ماهیت فدراسیون این است که تجربه ای متناقض را در برخی از انتهای شبکه فراهم کند.
وقتی سال گذشته مقاله را نوشتم ، صادقانه فکر کردم همه در حال ساخت سیستم های فدراسیون برای برای کاربران خود هستند ، نه برای آنها احساس گرما برای اجرای برخی از استانداردهای جدید. من اشتباه کردم ، و مردم اکنون پذیرفته اند که هر آنچه در پایان می آید احتمالاً راه حل خوبی برای کاربران آنها نیست و هر زمان که این نکته مطرح شود ، انتقاد صرفاً نادیده گرفته می شود. این امر عمداً انتظارات کاربر غیرفنی را زیر اتوبوس می اندازد.
"اما ما می توانیم برای سازگاری آن با یکدیگر صحبت کنیم"
با بالا رفتن پست وبلاگ اخیر مایکل وگل ، مردم اکنون ادعا می کنند که این اخطار پست اصلی من ، و من را کاملا گیج کرده است. من فکر نمی کنم که من هرگز ادعا کردم کاری که مایکل انجام داده غیرممکن است و نمی بینم که او در اینجا چه کسی سعی در تخریب دارد. وی در پست خود ، در مجموعه ای از نکات تا حدودی مربوط به پست من ، مسائل ناشی از ابهاماتی را که تجربه کرده و نحوه حل آنها را شرح می دهد. نتیجه گیری نهایی وی:
مشخصات جای تفسیر می گذارد. بنابراین - برای اطمینان از قابلیت همکاری - افراد مجری مختلف باید با یکدیگر صحبت کنند و باید در مورد راه حل هایی که برای همه مناسب است بحث کنند.
بنابراین در پایان ، من بسیار سپاسگزارم که او وقت خود را برای نوشتن این مقاله صرف کرد ، همانطور که هست نه تنها مقاله من را لغو نکرد ، بلکه در واقع همان چیزی را که من ادعا کردم را تأیید می کند.
مشکلی نیست اگر مجریان ترجیح می دهند کد دیگران را بخوانند تا بفهمند چه کاری باید انجام دهند ، و پرسیدن س toال از سایر پیاده سازی ها در صورت وجود چیزی نامشخص هیچ مشکلی ندارد. من تصدیق می کنم که زبان مورد استفاده در مشخصات می تواند کاملاً پیچیده باشد و این اسناد کمی طولانی تر هستند. افرادی که برای راهنمایی به سایر پیاده سازی ها مراجعه می کنند مسئله ای نیست ، من واقعاً می توانم این موضوع را به خوبی درک کنم.
این مسئله وقتی بوجود می آید که شما مجبور باشید کدهای منبع پروژه دیگر را بخوانید و هنگامی که مجبور باشید س askال کنید تا بتوانید چیزی را پیاده کنید. در این صورت ، دیگر دانش مورد نیاز برای اجرای قابل اعتماد این پروتکل دیگر در داخل مشخصات جمع آوری نمی شود ، بلکه در ردیاب اشکال ، قطعه کد منبع و مغز سایر افراد است. بدون دسترسی به این اطلاعات ، نمی توانید یک پیاده سازی قابل اعتماد بسازید.
این ممکن است برای برخی موارد استفاده و برخی مشخصات خوب باشد ، اما هنگام ساخت یک شبکه اجتماعی فدرال با پروتکل های ظاهراً باز ، این کاملاً غیر قابل قبول است . کاری که برخی از مجریان فعلی در حال حاضر انجام می دهند این است ، بهانه گیری ساده ، ساده لوحانه و نادان نسبت به همه به جز خودشان. من مطمئن هستم که آن افراد بسیار "اوه نگاه می کنند ، کار می کند!" لحظات این روزها ، و با خواندن این مقاله ، من نسبتاً مطمئن هستم كه بیشتر آنها به شدت با هر آنچه می نویسم مخالف خواهند بود زیرا اینكار برای آنها مفید است .
بگذارید یک پروژه آینده را تصور کنیم ، کار آنها را در دو سال دیگر شروع می کنیم. انتظار می رود چه کاری انجام دهند؟ هیچ مشخصات مرکزی برای بررسی آنها وجود نخواهد داشت . در آینده ممکن است بسیاری از پروژه های مختلف با استفاده از ActivityPub وجود داشته باشد ، بنابراین آیا انتظار می رود که مجری جدید از طریق همه کدهای خود و تمام ردیاب های اشکال خود جسارت کند؟ اگر آنها کد دیگران را درک نکنند چه اتفاقی می افتد؟ چه اتفاقی می افتد اگر افراد از پروژه های دیگر وقت یا علاقه ای برای پاسخ دادن به سوالات پروژه جدید نداشته باشند؟ چه اتفاقی می افتد اگر آنها تصمیم مهمی را از دست بدهند زیرا این تصمیم در بعضی از پروژه های GitLab گرفته شده است که کشف آن دشوار است؟ آیا واقعاً اجرای آینده باید به شانس بستگی داشته باشد؟
تنها هدف از مشخصات و ساختارهای پشتیبانی در اطراف آنها این است كه دقیقاً از این امر جلوگیری شود. مشخصات برای الهام گرفتن از کسی وجود ندارد. آنها می توانند منبع واحدی از حقیقت در س aboutالات مربوط به موضوعی باشند که می خواهند مشخص کنند. بحث در مورد مشخصات باید در در این مشخصات اتفاق بیفتد تا همه بتوانند در این فرایندها شرکت کنند و کل تاریخ را حتی در آینده حفظ و در دسترس همه قرار دهند.
شبکه اجتماعی فدرال هستی دنیایی است که بسیاری از مردم در مورد وب باز ، فرایندهای باز و استانداردهای آزاد عقاید محکم دارند. افرادی که با صراحت شکایت می کنند که چقدر همه چیز بد است وقتی یک فروشنده مرورگر تصمیم می گیرد تلاش خود را متوقف کند ، مقالاتی را درباره این که تصمیم گیری به خارج از سازمان های استاندارد سوق داده می شود ، می نویسند. افرادی که به دلیل تصمیمات رانندگی در فضای "غیر باز یا برای همه قابل مشاهده نیستند" به دیگران فریاد می زنند. و اما در اینجا ما هستیم ، همان افراد دقیقاً همان کارهایی را انجام می دهند که ادعا می کنند از آنها متنفرند.
چگونه مردم چگونه می توانند با هم کار کنند
من هرگز برای بازنویسی ActivityPub فشار نیاوردم ، و من هرگز تحت فشار قرار نگیرید تا قوانین سختگیرانه تری به خود ActivityPub یا Activity Streams اضافه شود. اگرچه من قوانین سختگیرانه تری خواسته ام ، اما چندین بار توضیح دادم که نیازی به این نیست که در داخل ActivityPub رخ دهد . مشکل داشتن حداکثر توسعه پذیری به عنوان یک هدف ضمن اطمینان از قابلیت همکاری سیستم ها و پیاده سازی ها چیز جدیدی نیست. این کار چند بار انجام شده است ، و نمونه های بسیار خوبی وجود دارد که فضای شبکه اجتماعی فدرال می توانست از آنها یاد بگیرد.
من می خواهم XMPP را به عنوان مثال در اینجا نگه دارم. اگر XMPP را نمی دانید ، کوتاه آن است Extensible Messaging and Presence Protocol ، یک پروتکل برای ساخت برنامه های توزیع شده پیام فوری. در حالی که توسعه پذیری بسیار مهم بود و حتی آن را به بخشی از نام پروتکل تبدیل کردند ، اما آنها نمی خواستند با مشخصات فراری که به داشتن مجریان برای گفتگو با یکدیگر بستگی دارد تا به طور قابل اعتماد کار کنند ، بستگی دارد.
آنها مجموعه ای کاملاً سخت و سختگیرانه از حداقل های مطلوب مورد نیاز برای ایجاد XMPP را نوشتند و این کار را از طریق مسیر استاندارد IETF انجام دادند و در نهایت به RFC 6120 منتهی می شوند. با تأیید اینکه هرگز نمی توانند همه نیازها را در چنین سند مشخصات دقیق برطرف کنند ، آنها خود را برای انعطاف پذیری بیشتر باز کردند:
این سند نحوه اتصال سرویس گیرنده ها به سرورها را مشخص می کند و معانی اصلی اصطلاحات XML را مشخص می کند. با این حال ، این سند "محموله های بار" مصراع های XML را که ممکن است پس از ایجاد موفقیت آمیز اتصال مبادله شود ، تعریف نمی کند. در عوض ، این محموله ها توسط پسوندهای مختلف XMPP تعریف می شوند. به عنوان مثال ، [XMPP-IM] برنامه های افزودنی برای پیام رسانی فوری و عملکرد حضور را تعریف می کند. علاوه بر این ، مشخصات مختلف تولید شده در سری XEP XSF [XEP-0001] برنامه های افزودنی را برای طیف گسترده ای از برنامه ها تعریف می کند.
آنها پروتکل های XEPs ، XMPP Extensions را معرفی کردند. اولین XEP که تاکنون منتشر شده است ، XEP-0001 ، فرایند انتشار XEP جدید در جهان را توصیف می کند ، و درک آن روند دشوار یا دشوار نیست. از همه دعوت شده است كه پیشنهادی را ارائه دهند ، شما نیازی به عضویت در هیچ سازمانی ندارید ، و در واقع ، شما حتی نیازی به حفظ اجرای خود ندارید. تا زمانی که پیشنهاد شما از قوانین پیروی کند و با قالب مورد نیاز مطابقت داشته باشد ، مورد توجه قرار می گیرد. پس از ارائه پیشنهادی ، زنجیره خاصی از وقایع وجود دارد ، اما این به بحثی آزاد درباره این پیشنهادات خلاصه می شود ، و اگر دیگر تردید یا چیزهایی برای بهبود وجود نداشته باشد ، و اگر مردم موافق باشند که این پیشنهاد مفید است موردی که باید استاندارد شود ، در نهایت پیشنهاد به عنوان XEP واقعی خاتمه می یابد.
در زمان نگارش ، 151 XEP فعال ، پیش نویس ، آزمایشی ، نهایی یا پیشنهادی وجود دارد و همه آنها را می توان در استاندارد XMPP یافت. وب سایت بنیاد هرکسی که علاقه مند به خواندن این موضوعات باشد ، به عنوان مثال به دلیل اینکه می خواهد یک سرویس گیرنده یا سرور را پیاده سازی کند ، می تواند اسناد را در آنجا پیدا کند و همچنین زیرساخت اصلی برای طرح س questionsال و پیشنهاد پیشرفت وجود دارد که برای همه آزاد است. به این ترتیب ، XSF تضمین کرده است که XMPP می تواند به همه موارد استفاده قابل تصور گسترش یابد ، بدون اینکه در انتها با مشخصات کم آب یا مبهم پایان یابد.
اگر به عنوان مثال ، من می خواستم یک سرور XMPP یا یک مشتری را اجرا کنم ، من می توانم RFC های مربوطه و همچنین XEP های مربوط به پروژه من را بخوانم. برخی از اسناد ، مانند XEP-0387 به عنوان مثال ، حتی می توانند با ذکر مواردی که هنگام ساختن یک سرویس گیرنده وب ، یا یک مشتری دسک تاپ پیشرفته یا یک برنامه تلفن همراه مهم هستند ، در تصمیم گیری درباره که XEPs ضروری است کمک کنند. ،… دیگر نیازی به مکالمه با سایر سرورهای XMPP یا مجری های سرویس گیرنده برای کار با من نیست و من می توانم در مورد قابلیت همکاری سیستم هایم بسیار راحت باشم اگر آنها را مطابق با مشخصات فنی.
بنیاد استاندارد ActivityUniverse Standards ، با همه کسانی که روی یک هیئت مدیره کار می کنند ، همان فرایند ارسال باز ، همان تأیید باز ، تصور زیادی نیست. گردش کار ، و اسناد مشخصات قابل اعتماد و کامل در پایان. می توان یک مجموعه پایه بسیار دقیق وجود داشت که کاملاً مورد نیاز بوده و مجموعه ای از پسوندهای اختیاری ، در کنار مکانیزمی برای کشف قابل اعتماد پشتیبانی از آن برنامه های افزودنی. علاوه بر این ، مجموعه پایه همچنین می تواند مشکل دریافت محتوایی را که گیرنده قادر به تجزیه نیست ، برطرف کند. شاید ما می توانستیم نمایشی جایگزین ارائه دهیم و شاید بتوانیم راهی برای جاسازی این مطالب مانند OEmbed با جعبه ماسه ایمن تر و ایمن تر در نظر بگیریم.
اگر همه تصدیق می کردند ، به طور شگفت آور تلاش کمی بود در وهله اول به آن نیاز دارند و برای ساختن حباب کوچک خود فرار نکردند. اکنون ، افراد از قبل سیستم هایی را در بالای مجموعه فعلی توافق نامه های متقابل ایجاد کرده اند ، پس چرا آنها باید حتی در تعیین چیزی که در نهایت با اجرای آنها ناسازگار است شرکت کنند و برای تنظیم آنها زمان بیشتری لازم است. حتی اگر ناگهان بسیاری از افراد توافق کنند که فضای شبکه فدراسیون باید اینگونه روی مسائل کار کند ، متأسفانه بعید به نظر می رسد که موفق شود. و این عمدتا به این دلیل است که بسیاری از مردم در وهله اول علاقه ای به بحث و گفتگوهای معنادار نداشتند.
نتیجه گیری
صادقانه بگویم ، من در نتیجه گیری در اینجا مشکل دارم.
جای تعجب نیست که فضای شبکه های اجتماعی فدرال یک فضای دشوار است. هر کس با استفاده از یا مشغول کار بر روی یک نرم افزار در این فضا بسیار عقیده دارد و احتمالاً در درجه اول دلایل شخصی برای انجام کار دارد. با این حال ، این معمولاً چیز خوبی است. به نظر می رسد احتمالاً چیز خوبی نیست. داشتن بحث های معنادار در مورد ماهیت ActivityPub غیرممکن است وقتی که بعضی از افراد جلوتر می روند و از هرچیزی که شما می گویید چشم پوشی می کنند زیرا آنها شما را بعنوان یک شخص دوست ندارند. من انتظار داشتم که مردم بتوانند بین نظر شخصی و نظر شغلی خود تفاوت قائل شوند ، اما به نظر می رسد که حتی امروز نیز افراد زیادی قادر به انجام چنین کاری نیستند. به جای اینکه استدلالهایی را که در طول سال گذشته بارها و بارها در نظر گرفته ام در نظر بگیرم ، نادیده گرفتن آنها راحت تر و راحت تر است. این می توانست فضای بهتری باشد.
از نظر من ، تقریباً کمی خنده دار است وقتی که مردم پیشنهاد می کنند دیاسپورا * سوراخ خود را حفر می کند یا ادعا می کند هرچه خودمان اختراع نکرده ایم ، فقط برای یک قدم به عقب بردن و س questionال کردن اگر ما ، به عنوان یک مجموعه اجتماعی وب ، کارهای درستی انجام می دهیم ، یا اگر باید کاری متفاوت انجام دهیم. من واقعاً برایم مهم نیست که اگر دیاسپورا در پایان از بین برود ، و در واقع اگر چیزی بهتر وجود داشته باشد ، خوشحال می شوم که بمیرد. اما برای این که اتفاق بیفتد ، باید مطمئن باشیم که واقعاً چیز بهتری را می سازیم. این کار با همکاری حاصل می شود ، نه با سرهم کردن سر یکدیگر به دلایل شخصی.
اصلاحات
- 2019-01-14 : کوری اسلپ با وبلاگ خود به من رسیده است پست منتشر شده در حالی که من این را می نوشتم. در اینجا برخی نظرات همپوشانی وجود دارد و همچنین خوانش جالبی است. آنها فرض می کنند که اکثر افراد برای ساختن راه حل های سازگار تلاش می کنند و اکثر مردم علاقه مند به حفظ آن به عنوان یک هدف بلند مدت هستند ، اما کمی در سمت خوشبین هستند. در حالی که من امیدوارم چنین اتفاقی بیفتد ، اما نمی خواهم این فضا بر اساس امیدهای کسی باشد. اگر افراد قبلاً بحث داشته اند ، پس چرا کسانی که در یک نهاد مرکزی هستند بحث نمی کنند و در نهایت نتایج را در اسناد مشخصات مرجع ارائه می دهند؟
- 01/01/2019 : همچنین مجموعه ای از پست های وبلاگ توسط kaniini ، یکی از افراد پشت Pleroma وجود دارد که ActivityPub را به عنوان رویکرد "بدتر از این بهتر" به شبکه های اجتماعی فدرال توصیف می کند. این پست ها در مورد برخی از چالش های موجود در زمینه اجرای یک برنامه AcitivyPub با جزئیات فنی بسیار جزئی است ، و گرچه من با همه آنچه آنها می گویند موافق نیستم ، برخی از نکات معتبر هستند.
ضمیمه
این پست مرا مجبور به تماس کرد برخی از گروه ها ، و افراد خاص. می خواهم تأکید کنم که حتی یک نکته در لیست درگیری های بین فردی من مربوط به هیچ یک از افرادی نیست که به طور چشمگیری در ایجاد مشخصات ActivityPub و فشار جریان فعالیت فعالیت داشته اند. کاملاً برعکس این امر صادق است ، هر بار که با برخی از آن افراد تعامل داشتم ، در نهایت بسیار سازنده و دوستانه بود و من هنوز هم نسبت به نویسندگان احترام زیادی برای آنچه که به دست آورده اند ، دارم. هر زمان که من در این مقاله در مورد افراد صحبت می کنم ، صریحاً در مورد کسانی که کارهای بزرگی انجام داده اند صحبت نمی کنم. این مشکل عمدتا در گروه متفاوتی از مردم نهفته است. من سعی کردم این موضوع را روشن کنم ، اما لطفا در صورت نگرانی با من تماس بگیرید یا حتی شخصاً خود را آزرده احساس کنید.
برخی از نقل قول های موجود در این مقاله ، به ویژه نقل قول های افراد با کاملا مخالف هستند من در سطح شخصی ، بدون پیوند دادن منبع ساخته شده ام. همچنین ، ضمن اطمینان از سالم نبودن ماده ، متن را تغییر دادم تا کشف آنها با استفاده از موتورهای جستجو کمتر باشد. اگرچه این اظهارات در ملا public عام بیان شده است ، اما انگشت گذاشتن به شخص دیگر معنایی ندارد. من بطور مثال این افراد را نقل می کنم تا در مورد استدلالهای استفاده شده بر خلاف نظر من نکته ای را ذکر کنم ، و جدا کردن افراد فقط به اختلافات شخصی دامن می زند ، که من اصلاً علاقه ای به آنها ندارم.