«داده‌های غیرعمومی»؛ قابلیت جدید پروتکل AT برای توسعه‌دهندگان دپ‌اپ‌ها

تصور کنید در یک شبکه اجتماعی حضور دارید که پروفایل شما برای همه باز است، اما یک «باغ دیجیتال» خصوصی برای پیش‌نویس‌ها و یادداشت‌های شخصی دارید که هیچ‌کس جز شما نمی‌بیند. این دقیقاً همان شکافی است که قابلیت جدید Spaces در پروتکل AT پر می‌کند.

طبق اعلام رسمی در ۲۰ اوت ۲۰۲۶، نسخه آلفای Spaces اکنون به توسعه‌دهندگان اجازه می‌دهد محیط‌های محدود و غیرعمومی بسازند. این به‌روزرسانی یک ابزار بنیادی (Primitive) را معرفی می‌کند که اجازه می‌دهد داده‌ها بدون پخش عمومی در شبکه، ذخیره و همگام شوند.

تا پیش از این، هر پست، دنبال کردن یا لایک در این پروتکل به‌طور پیش‌فرض کاملاً عمومی بود. این باز بودن باعث شد اپلیکیشن‌هایی مثل Bluesky و Tangled بتوانند روی یک شبکه «قفل‌باز» به‌سرعت رشد کنند. با این حال، همین معماری باعث می‌شد ساخت محصولاتی که به حریم خصوصی نیاز داشتند — مانند انتشار محتوای صرفاً اشتراکی (Subscription-only) یا تنظیمات خصوصی کاربر — غیرممکن باشد.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی حاکمیت داده در شبکه‌های غیرمتمرکز اشاره کردیم، تعادل بین شفافیت و حریم خصوصی همواره چالش اصلی بوده است. Spaces اکنون این امکان را فراهم می‌کند تا از فایل‌های کوچک تنظیمات شخصی تا انجمن‌های عظیم با میلیون‌ها عضو، در محیط‌های کنترل‌شده مدیریت شوند.

سیر تکامل و زمینه

این پروژه پیش از رسیدن به نام نهایی «atproto spaces»، مسیر طولانی را طی کرده و تغییرات هویتی متعددی داشته است. این قابلیت در مراحل اولیه با نام‌هایی چون «داده‌های خصوصی» (Private Data)، سپس «داده‌های مجاز» (Permissioned Data) و برای مدتی کوتاه به عنوان «سطل‌ها» (Buckets) شناخته می‌شد.

طراحی این سیستم از طریق یک فرآیند مشارکتی گسترده با حضور کل اکوسیستم تکامل یافت. این مسیر شامل گفتگوهای اولیه در تالارهای گفتگو (Forum)، انتشار یک دفترچه یادداشت توسعه (Development Diary) در ماه فوریه و در نهایت ارائه یک پیشنهاد جامع (Full Proposal) بود. نتیجه این تلاش‌ها، یک پروژه بزرگ و حیاتی هم برای تیم Bluesky و هم برای جامعه گسترده‌تر Atmosphere است.

سازوکار Spaces

یک فضای (Space) در پروتکل AT مانند نسخه‌ای کوچک، سبک و مینیاتوری از کل شبکه عمل می‌کند. این ساختار اجازه دسترسی محدود (Gated Access) را می‌دهد، به طوری که تنها افراد و اپلیکیشن‌های خاصی می‌توانند داده‌های منتشرشده در آن فضا را مشاهده کنند.

ویژگی‌های فنی کلیدی این سیستم عبارتند از:

• مقیاس‌پذیری: یک فضای کاری می‌تواند بسیار کوچک باشد و تنها یک رکورد را با کمترین سربار (Overhead) نگه دارد، یا تا مقیاس یک میلیارد رکورد گسترش یابد.
• هویت: کاربران همچنان از شناسه‌های غیرمتمرکز (DID) — شبیه به یک شماره شناسایی جهانی و منحصر‌به‌فرد که به هیچ سازمان مرکزی وابسته نیست — استفاده می‌کنند و داده‌ها را در مخازن (Repositories) خودشان میزبانی می‌کنند.
• ساختار: رکوردها همچنان بر پایه JSON هستند و توسط Lexicons تعریف می‌شوند.
• کنترل: دسترسی توسط یک «مرجع فضای کاری» (Space Authority) مدیریت می‌شود. این مرجع در واقع یک DID است که تعیین می‌کند چه کسی اجازه ورود به فضا را دارد. در برخی موارد، مرجع فضای کاری همان حساب کاربری خود شخص است.
• ذخیره‌سازی: رکوردها در مخازن مجازِ هر فضا (Per-space permissioned repositories) روی سرور داده شخصی (PDS) نویسنده ذخیره می‌شوند.

به نقل از مستندات atproto.com، باید توجه داشت که Spaces کنترل دسترسی (Access Control) را فراهم می‌کند، نه محرمانگی (Confidentiality) مطلق. داده‌های درون یک فضا رمزنگاری نشده‌اند و صرفاً دسترسی به آن‌ها محدود شده است؛ یعنی هر کاربر یا اپلیکیشنی که اجازه ورود به آن فضا را داشته باشد، می‌تواند داده‌ها را بخواند.

کاربردهای عملی و انعطاف‌پذیری

این ابزار به عنوان یک زیرساخت منعطف با طیف گسترده‌ای از کاربردهای هدفمند طراحی شده است:

• داده‌های شخصی: کوچک‌ترین فضاها دقیقاً یک عضو دارند. این‌ها برای ذخیره تنظیمات، پیش‌نویس‌ها و بوک‌مارک‌های خصوصی ایده‌آل هستند.
• محتوای محدود: ناشران می‌توانند از Spaces برای توزیع نشریاتی استفاده کنند که دسترسی به آن‌ها فقط برای مشترکین پرداخت‌کننده یا مجاز است.
• بسترهای اجتماعی مشترک: بزرگ‌ترین فضاها برای انجمن‌هایی طراحی شده‌اند که ممکن است تا میلیون‌ها شرکت‌کننده داشته باشند و نیاز به یک محیط مشترک اما غیرعمومی دارند.

زیرساخت و همگام‌سازی

برخلاف داده‌های عمومی که از یک رله (Relay) برای پخش محتوا در سراسر شبکه استفاده می‌کنند، داده‌های Spaces مستقیماً از میزبان‌های PDS همگام می‌شوند. دلیل این امر آن است که بازپخش (Rebroadcasting) محتوا برای فضاهای خصوصی اغلب نامطلوب و غیرضروری است.

این همگام‌سازی مستقیم، پروتکل را به طور قابل توجهی سبک‌تر کرده و آن را برای به‌روزرسانی‌های آنی (Real-time) مناسب‌تر می‌کند. برای تسهیل آزمایش، تیم توسعه یک محیط Sandbox میزبانی‌شده فراهم کرده است. توسعه‌دهندگان می‌توانند از طریق حساب‌های BPS خود، کدهای دعوت دریافت کنند تا بدون نیاز به راه‌اندازی زیرساخت شخصی، این قابلیت را تست کنند.

برای کسانی که کنترل محلی را ترجیح می‌دهند، یک تصویر داکر (Docker image) در آدرس ghcr.io/bluesky-social/atproto:pds-spaces-alpha در دسترس است. این تصویر با توزیع مرجع PDS سازگار است و به هیچ پیکربندی جدیدی نیاز ندارد.

پذیرش در اکوسیستم

چندین پروژه جامعه‌محور از همین حالا پیاده‌سازی این مشخصات (Spec) را آغاز کرده‌اند، از جمله:

• ZDS: یک PDS نوشته شده با زبان برنامه‌نویسی Zig.
• atproto-crates: پیاده‌سازی PDS بر پایه زبان Rust.
• rsky: یک PDS دیگر با زبان Rust که توسط Blacksky مدیریت می‌شود.
• HappyView: یک چارچوب AppView.

یک نمونه زنده از این فناوری، اپلیکیشن Bulletin (در دسترس در https://bulletin.my) است. این برنامه به کاربران اجازه می‌دهد یک تابلوی اعلانات به عنوان یک Space ایجاد کنند که در آن فقط دنبال‌کنندگان متقابل (Mutual Followers) می‌توانند یادداشت‌های چسبان (Sticky Notes) بگذارند. این دقیقاً همان «بستر اجتماعی مشترک» است که تیم توسعه در نظر داشت. کد این پروژه در گیت‌هاب برای بازبینی، فورک کردن و بازسازی توسط توسعه‌دهندگان در دسترس است.

محدودیت‌ها و ریسک‌های نسخه آلفا

تیم توسعه هشدارهای شدیدی درباره وضعیت آلفای این نرم‌افزار داده است. آن‌ها صراحتاً اعلام کرده‌اند که کدها هنوز تحت بررسی امنیتی کامل (Full Security Review) قرار نگرفته‌اند و نباید برای داده‌های حساس تولیدی (Production) استفاده شوند.

کاربران باید بدانند که:

• پایداری داده‌ها: داده‌ها دائمی نیستند و ممکن است بدون هشدار حذف شوند. هیچ مسیر بازیابی (Recovery path) برای داده‌های حذف شده وجود ندارد.
• تغییرات فنی: طرح‌های پایگاه‌داده (Database schemas) ممکن است بدون مهاجرت‌های تمیز (Clean migrations) تغییر کنند. کاربران نباید انتظار ارتقای بدون نقص بین نسخه‌ها را داشته باشند.
• چرخه عمر: سرورهای PDS میزبانی‌شده در پایان دوره آلفا کاملاً حذف خواهند شد. بنابراین نباید به حساب‌های ایجاد شده روی آن تکیه کرد.
• امنیت: به دلیل عدم بازبینی کامل کدها، آپلود اطلاعات حساس به شدت توصیه نمی‌شود.

برای حفظ محیط Sandbox، تیم توسعه کاربرانی را که باعث ایجاد مشکلات نظارتی شوند یا از شبکه به شکلی غیرسازنده سوءاستفاده کنند، به‌طور دائمی مسدود خواهد کرد.

مسیر رسیدن به نسخه نهایی

چرخه توسعه تا پایان پاییز ادامه خواهد داشت و به‌روزرسانی‌های SDKها و PDS میزبانی‌شده هر پنج‌شنبه منتشر می‌شود. تغییرات در رشته اعلان‌های atmosphere.community ثبت می‌گردد.

توسعه‌دهندگان می‌توانند از طریق مخزن Proposals در این پروژه عمیق‌تر شوند، زیرا این مخزن نقطه اصلی همکاری است. پیاده‌سازی مرجع در شاخه atproto spaces مخزن اصلی قرار دارد، هرچند ممکن است به طور موقت با بسته‌های منتشر شده تفاوت داشته باشد.

برای پشتیبانی از این روند، بسته‌های TypeScript @atproto به صورت نسخه‌های Snapshot آلفا منتشر شده‌اند که با تگ alpha قابل نصب هستند. هدف نهایی، عرضه کامل این قابلیت در اواخر سال ۲۰۲۶ است.

این تغییر، این فرض را که پروتکل‌های اجتماعی غیرمتمرکز باید در مورد حریم خصوصی «یا همه یا هیچ» باشند، به‌کلی تغییر می‌دهد. با معرفی لایه مجاز، پروتکل AT به سمت یک مدل ترکیبی حرکت می‌کند که هم از فضای عمومی جهانی (Global Commons) و هم از فضاهای دیجیتال خصوصی پشتیبانی می‌کند.

برای توسعه‌دهندگان، این به معنای توانایی ساخت اپلیکیشن‌های خصوصی «بازسازی‌پذیر» (Remixable) است. اکنون می‌توانید ابزاری بسازید که داده‌های خصوصی کاربر را در PDS خودش ذخیره کند، اما به یک اپلیکیشن مجاز اجازه دهد آن داده‌ها را همگام و نمایش دهد، در حالی که حاکمیت کاربر بر اطلاعاتش حفظ شده است.

گام بعدی شما

• اگر توسعه‌دهنده هستید، از تصویر داکر pds-spaces-alpha برای تست محیط‌های محدود استفاده کنید.
• اپلیکیشن Bulletin را بررسی کنید تا درک کنید «بسترهای اجتماعی مشترک» در عمل چگونه کار می‌کنند.
• برای دریافت کدهای دعوت Sandbox، به حساب BPS خود مراجعه کنید.

اما این تنها بخشی از معماری جدید است؛ تأثیر این تغییر بر مدل‌های کسب‌وکار اشتراکی در وب ۳ را در گزارش بعدی بررسی خواهیم کرد.