ألقى جيك لازاروف محاضرة جادل فيها بأن بروتوكول AT (atproto) يمكن استخدامه كأساس للتطبيقات الموزعة، وليس فقط كبنية تحتية للشبكات الاجتماعية. ركزت الجلسة على البنية المحلية الأولى التي يقوم فيها المستخدمون بتخزين بياناتهم الخاصة في خوادم البيانات الشخصية (PDS)، بينما تستخدم التطبيقات البنية التحتية للبروتوكول المشترك للتخزين والترخيص والمزامنة والتحديثات. كان ادعاؤه المركزي هو أن بروتوكول AT يمكن أن يقلل الاعتماد على خدمات الواجهة الخلفية الخاصة بالتطبيق ويساعد في تجنب نقاط الفشل الفردية.
افتتح لازاروف حديثه بقصة من تطبيق تخطيط السفر الذي أنشأه خلال إجازة تفرغ. يستخدم التطبيق YJS مع خادم مزامنة مُدار. وبعد مرور عام تقريبًا، تم الحصول على مزود المزامنة وإغلاقه. لا يزال التطبيق يعمل محليًا، لكن المزامنة بين الأجهزة المتعددة لم تعد تعمل، مما يترك الملف اليدوي يمرر كبديل. لقد استخدم هذا المثال لتوضيح التوتر الأوسع بين البنية التحتية التعاونية والمرونة: نفس الخادم الذي أتاح المزامنة عبر الأجهزة أصبح أيضًا أضعف تبعية للتطبيق.
ثم وصف أتبروتو بأنه نموذج معماري بديل. بدلاً من أن يحتفظ كل تطبيق بواجهة خلفية منعزلة خاصة به، احتفظ كل مستخدم بالبيانات في نظام التوزيع العام (PDS) ومنح التطبيقات حق الوصول إليها. في هذا النموذج، يوفر نظام التوزيع العام (PDS) مساحة تخزين ومصادقة دقيقة ودفع التحديثات. وصف لازاروف عرض التطبيق، وهو خادم مخصص لكل تطبيق في بنية atproto القياسية، بأنه اختياري وباعتباره النقطة الأضعف في المكدس.
غطى الجزء الرئيسي من المحاضرة ثلاث تجارب أدت إلى إزالة عرض التطبيق بالكامل واعتمدت فقط على التطبيقات الثابتة، وأجهزة التوزيع العامة (PDS)، والمرحلات. في البداية، قام لازاروف ببناء محرر نصوص تعاوني باستخدام YJS وProseMirror. تمت كتابة كل تحديث لـ YJS كسجل لنظام التوزيع العام (PDS) الخاص بالمستخدم. تم إدراج المتعاونين في سجل البيانات التعريفية، وقام الزملاء بجلب تحديثات بعضهم البعض وتكرارها من خلال التتابع في الوقت الفعلي تقريبًا. وقال إن هذا يستخدم بشكل فعال atproto كخادم مزامنة YJS. كان التحدي الرئيسي في هذا النهج هو أن حالة المستند كانت منتشرة عبر العديد من السجلات، مما جعل إمكانية التشغيل التفاعلي مع التطبيقات الأخرى أكثر صعوبة.
نفذت التجربة الثانية قائمة مهام تعاونية باستخدام سجلات CRDT الأصلية. كانت السجلات عبارة عن كائنات JSON عادية تحتوي على حقول مثل `$type` و`listId` و`text` و`done` و`createdAt`، مع إرفاق بيانات تعريف CRDT بشكل منفصل. وقال لازاروف إن هذا جعل السجلات واضحة بذاتها، حتى بالنسبة للتطبيقات التي تجاهلت بيانات تعريف CRDT. استخدم التصميم سجلات آخر فوز في الكتابة لكل حقل، مما أدى إلى تجنب التعارضات عندما تمس التعديلات المتزامنة حقولاً مختلفة. عندما تستهدف عمليات الكتابة المتزامنة نفس السجل، يرفض منطق المقارنة والمبادلة الكتابة، وبعد ذلك يقوم العميل بإحضار أحدث حالة، ودمجها محليًا، وإعادة المحاولة. كان التحدي الرئيسي في هذه الحالة هو التعامل مع عمليات الكتابة المتزامنة لنفس السجل دون فقدان التحديثات أو كسر نموذج CRDT.
وفي التجربة الثالثة، استخدم لازاروف atproto كآلية إرسال إشارات لدردشة الفيديو عبر WebRTC. كتب أحد الأقران سجلات مرشح ICE (مؤسسة الاتصال التفاعلي) إلى PDS مع تسمية المستلم المقصود، واستمع النظير الآخر من خلال المرحل واستجاب، ثم أنشأ الزملاء اتصال WebRTC مباشرًا. أثناء العرض التوضيحي المباشر، تطلبت ظروف شبكة Wi-Fi الخاصة بالمؤتمر استخدام مرحل TURN (الاجتياز باستخدام المرحلات عبر NAT)، والذي أشار إليه باسم “خادم TURN العار”. واقترح أيضًا أن قنوات بيانات WebRTC يمكن أن تكمل atproto من خلال توفير النقل في الوقت الفعلي للتطبيقات المحلية أولاً. كان التحدي الرئيسي هنا هو اجتياز الشبكة، نظرًا لأن اتصال المؤتمر غير الموثوق به حال دون الاتصال النظيف والمباشر من نظير إلى نظير والرجوع القسري إلى البنية الأساسية لـ TURN.
خلال الحديث، جادل لازاروف بأنه يجب على المطورين البناء على البنية التحتية المشتركة بدلاً من الخوادم الخاصة بكل تطبيق. واستشهد بفكرة أن الخوادم يجب أن تظل بسيطة وعامة وقابلة للاستبدال. وأشار إلى العديد من مضيفي PDS المستقلين، والمرحلات العامة المجانية، وجهود التجميع المدعومة من المجتمع كعلامات على أن atproto تدعم بالفعل هذا الاتجاه. في المناقشة الختامية، تركزت أسئلة الجمهور على المفاضلات بين قابلية التشغيل البيني والمزامنة ونشر WebRTC. ظلت الفكرة الرئيسية ثابتة طوال المحادثة: تم تقديم atproto كأساس قابل للتطبيق للتطبيقات الموزعة، وليس فقط للمنصات الاجتماعية.
