چرا حساب‌های بلواسکای می‌توانند بین سرورها جابه‌جا شوند اما حساب‌های مستودون نه؟

وقتی یک شبکه اجتماعی غیرمتمرکز از مرز ۱۰ میلیون کاربر ثبت‌نام‌شده عبور می‌کند - آستانه‌ای که بلواسکای (Bluesky) در اواخر سال ۲۰۲۴ از آن گذشت - زیرساختی که داده‌های آن‌ها را نگه می‌دارد معمولاً به یک تله دائمی تبدیل می‌شود. اگر بر اساس جمعیت دیجیتال بسنجیم، ۱۰ میلیون نفر به اندازه یک کشور کوچک است. در معماری سنتی وب، جابه‌جایی این جمعیت نیازمند اجازه صریح میزبان است. اگر سرور خاموش شود، هویت نیز از بین می‌رود. هم پروتکل AT و هم ActivityPub خود را به عنوان راه‌حل‌های «غیرمتمرکز» برای این بن‌بست بازاریابی می‌کنند و به کاربران وعده کنترل بر گراف‌های اجتماعی‌شان را می‌دهند. اما این ادبیات بازاریابی، یک تفاوت ساختاری عمیق در نحوه مسیریابی واقعی داده‌ها توسط این دو سیستم را پنهان می‌کند.[4][6]

پروتکل ActivityPub که در ژانویه ۲۰۱۸ توسط کارگروه اجتماعی W3C نهایی شد، پلتفرم‌های فدرال مانند مستودون (Mastodon) و پیکسل‌فد (Pixelfed) را قدرت می‌بخشد. این پروتکل بر اساس مدل انتقال سند کار می‌کند. وقتی کاربری پستی را منتشر می‌کند، سرور او آن را به عنوان یک سند JSON-LD رمزگذاری کرده و به صندوق ورودی دنبال‌کنندگانش در سرورهای راه دور ارسال می‌کند. این یک مکانیزم بسیار کارآمد برای ارتباط بین سرورهاست، اما هویت کاربر را کاملاً به دامنه میزبان گره می‌زند.[1][5]

تحت پروتکل ActivityPub، یک هویت با استفاده از WebFinger و با فرمت `acct:[email protected]` تفکیک می‌شود. از آنجا که نام دامنه ریشه هویت است، کاربر از نظر رمزنگاری مالک حساب خود نیست؛ بلکه این مدیر سرور است که مالکیت را در اختیار دارد. اگر یک برنامه راه دور از سروری درباره حسابی که غیرفعال شده یا بدون تغییر مسیر (redirect) جابه‌جا شده است پرس‌وجو کند، نقطه پایانی (endpoint) به سادگی خطای 405 Method Not Allowed یا 400 را برمی‌گرداند و اتصال را کاملاً قطع می‌کند. هیچ مکانیزم بومی برای ادغام یا همگام‌سازی لیست دنبال‌کنندگان در بین سرورها وجود ندارد.[1][2]

اگر یک کاربر ActivityPub بخواهد به سرور جدیدی نقل مکان کند، باید از یک فعالیت «انتقال» (Move) استفاده کند. این کار مستلزم آن است که سرور قدیمی آنلاین و همکار باقی بماند و یک اعلان تغییر مسیر را در پروفایل اصلی قرار دهد. اگر سرور اصلی از کار بیفتد، ورشکست شود یا مدیر آن رویکردی خصمانه پیش بگیرد، هویت برای همیشه نابود می‌شود. کاربر باید از صفر در یک دامنه جدید شروع کند.[2][5]

پروتکل AT با جدا کردن هویت رمزنگاری‌شده از میزبانی فیزیکی داده‌ها، به این مشکل نزدیک می‌شود. به جای یک آدرس متصل به دامنه، یک کاربر پروتکل AT با یک شناسه غیرمتمرکز (DID) شناسایی می‌شود. این DID به عنوان فهرستی از کلیدهای رمزنگاری عمل می‌کند که کاملاً مستقل از محل واقعی ذخیره فایل‌های کاربر است.[3]

میزبانی فیزیکی توسط یک سرور داده شخصی (PDS) انجام می‌شود. این PDS داده‌های اولیه کاربر - پست‌ها، لایک‌ها و دنبال‌کردن‌ها - را در یک فایل آرشیو آدرس‌پذیر محتوا (CAR) ذخیره می‌کند که معمولاً برای کاربران پرمصرف به حدود ۵۰ مگابایت محدود می‌شود. اگر PDS آفلاین شود، هویت کاربر دست‌نخورده باقی می‌ماند زیرا DID در یک رجیستری جداگانه ذخیره شده است. مستندات رسمی پروتکل AT این هدف را به صراحت بیان می‌کند: «هدف پروتکل AT این است که اطمینان حاصل کند کاربر می‌تواند حساب خود را بدون دخالت سرور به یک PDS جدید منتقل کند.»[3][4]

برای اجرای یک مهاجرت خصمانه - یعنی انتقال داده‌ها زمانی که میزبان قدیمی از کار افتاده یا همکاری نمی‌کند - کاربر به یک کلید چرخش (rotation key) متکی است. این یک شاه‌کلید رمزنگاری‌شده است که تغییرات را در سند DID اعمال می‌کند. کاربر یک سند DID جدید را امضا می‌کند که به PDS جدید او اشاره دارد، فایل CAR پشتیبان‌گیری‌شده خود را آپلود می‌کند و شبکه موقعیت او را به‌روزرسانی می‌کند. در این فرآیند، سرور قدیمی به طور کامل دور زده می‌شود.[3]

با این حال، واقعیتی که اکنون عرضه شده است، با قابلیت‌های معماری آن فاصله دارد. در حالی که این پروتکل از کلیدهای چرخش تحت کنترل کاربر - که روی یک دستگاه سخت‌افزاری یا نسخه پشتیبان کاغذی ذخیره می‌شوند - پشتیبانی می‌کند، اکثر کاربران بلواسکای در واقع آن‌ها را در اختیار ندارند. برای راحتی عملیاتی، شرکت Bluesky Social PBC کلیدهای چرخش اکثریت قریب به اتفاق ۱۰ میلیون کاربر خود را مدیریت می‌کند. قابلیت مهاجرت یک‌جانبه در کد وجود دارد، اما اجرای عملی آن تا زمانی که کاربران حضانت کلیدهای خود را بر عهده نگیرند، متمرکز باقی می‌ماند.[3][6]

پروتکل AT همچنین استقلال سرور را فدای مقیاس‌پذیری در سطح شبکه می‌کند. به جای ارسال مستقیم اسناد بین سرورها مانند ActivityPub، پروتکل AT از یک سرویس خزنده (crawler) برای استخراج سوابق از هر PDS استفاده می‌کند و آن‌ها را از طریق WebSockets به سرورهای نمایه‌سازی عظیمی به نام رله‌ها (Relays) استریم می‌کند. این رله‌ها فعالیت کل شبکه را در یک جریان داده واحد (firehose) تجمیع می‌کنند.[4][6]

حفظ این جریان داده به منابع قابل‌توجهی نیاز دارد. زمانی که شبکه در اواسط سال ۲۰۲۴ دارای ۶ میلیون کاربر بود، نگهداری یک کپی در لحظه از تمام مخازن کاربران روی یک سرور واحد، ماهانه حدود ۱۵۳ دلار هزینه داشت. این رقم تنها شامل پهنای باند ورودی و فضای ذخیره‌سازی می‌شد و توان محاسباتی مورد نیاز برای ساخت و ارائه نمایه‌های خلاصه را در بر نمی‌گرفت.[6]

این معماری به این معناست که در حالی که هر کسی می‌تواند یک PDS را روی یک سرور خصوصی مجازی ارزان‌قیمت میزبانی کند، اجرای یک رله یک عملیات در مقیاس سازمانی است. پروتکل ActivityPub بار محاسباتی را به طور مساوی در سراسر شبکه توزیع می‌کند و تمرکززدایی واقعی را به قیمت از دست دادن جستجو و کشف جهانی در اولویت قرار می‌دهد. پروتکل AT لایه نمایه‌سازی را متمرکز می‌کند تا ویژگی‌های جهانی را فعال سازد و تجربه کاربری و انتقال‌پذیری حساب را در اولویت قرار می‌دهد.[1][4]

این تفاوت فنی، آینده هر دو شبکه را تعریف می‌کند. پروتکل ActivityPub تضمین می‌کند که جوامع کوچک می‌توانند زیرساخت‌های کاملاً مستقلی را اجرا کنند، اما کاربران را مجبور می‌کند تا برای هویت دیجیتال خود به مدیران سرورشان اعتماد کنند. پروتکل AT از نظر ریاضی تضمین می‌کند که کاربران می‌توانند ارائه‌دهندگان میزبانی خود را اخراج کنند، به شرطی که حضانت کلیدهای چرخش خود را بر عهده بگیرند، در حالی که برای قابل استفاده کردن شبکه به نمایه‌سازهای سنگین و متمرکز متکی است.[3][5][6]