بروتوكول AT كأساس للتطبيقات اللامركزية: ثلاث تجارب تتخطى حدود Bluesky

أبرز النقاط

• بروتوكول AT يمكن أن يحل محل البنية الخلفية التقليدية للتطبيقات التعاونية
• ثلاث تجارب عملية أثبتت إمكانية الاستغناء عن App View كلياً
• النهج يعالج مشكلة الاعتماد على مزودي خدمات المزامنة الذين قد يتوقفون فجأة

ماذا يحدث حين تبني تطبيقاً تعاونياً يعتمد على خدمة مزامنة خارجية، ثم تُستحوذ تلك الخدمة وتُغلق؟ هذا السيناريو الكابوسي ليس نظرياً، بل حدث فعلاً مع المطور Jake Lazaroff حين توقف مزود المزامنة الذي اعتمد عليه تطبيقه للتخطيط السفري. في محاضرة حديثة، طرح Lazaroff بديلاً معمارياً جذرياً: استخدام بروتوكول AT كأساس لبناء تطبيقات موزعة تتجاوز حدود الشبكات الاجتماعية.

لماذا تحتاج التطبيقات التعاونية إلى بنية جديدة؟

المشكلة الجوهرية التي يعالجها هذا النهج واضحة: كل تطبيق تعاوني يحتاج إلى بنية خلفية للمزامنة، وهذه البنية تصبح نقطة الفشل الوحيدة. حين يتوقف الخادم، يتوقف التعاون. تطبيق Lazaroff كان يستخدم مكتبة YJS مع خادم مزامنة مُدار، وبعد عام تقريباً استُحوذ على المزود وأُغلق. التطبيق استمر في العمل محلياً، لكن المزامنة بين الأجهزة انتهت.

بروتوكول AT يقدم نموذجاً معمارياً مختلفاً: بدلاً من أن يحتفظ كل تطبيق بخادمه الخاص، يحتفظ كل مستخدم ببياناته في خادم بيانات شخصي (PDS) ويمنح التطبيقات صلاحية الوصول إليها. الخادم الشخصي يوفر التخزين والمصادقة الدقيقة والتحديثات الفورية. أما الـ App View، وهو الخادم المخصص لكل تطبيق في البنية التقليدية لبروتوكول AT، فهو اختياري ويمثل النقطة الأضعف في المنظومة.

التجربة الأولى: محرر نصوص تعاوني بدون خادم مركزي

بنى Lazaroff محرر نصوص تعاوني باستخدام YJS وProseMirror. كل تحديث من YJS يُكتب كسجل في خادم PDS الخاص بالمستخدم. المتعاونون يُدرجون في سجل metadata، والأقران يجلبون تحديثات بعضهم عبر الـ Relay في الوقت شبه الفوري. النتيجة: استخدام بروتوكول AT كخادم مزامنة YJS.

التحدي الرئيسي هنا أن حالة المستند موزعة على سجلات متعددة، مما يُصعّب التشغيل البيني مع تطبيقات أخرى قد ترغب في قراءة المستند.

التجربة الثانية: قائمة مهام تعاونية بسجلات CRDT أصلية

النهج الثاني استخدم سجلات CRDT أصلية بدلاً من تغليف YJS. السجلات كانت كائنات JSON بسيطة تحتوي حقولاً مثل نوع السجل ومعرف القائمة والنص وحالة الإنجاز وتاريخ الإنشاء، مع metadata الـ CRDT مرفقة بشكل منفصل.

• السجلات تشرح نفسها بنفسها حتى للتطبيقات التي تتجاهل metadata الـ CRDT
• التصميم يستخدم last-write-wins registers لكل حقل، مما يتجنب التعارضات حين تمس التعديلات المتزامنة حقولاً مختلفة
• عند تعارض كتابات متزامنة على نفس السجل، منطق compare-and-swap يرفض الكتابة، فيجلب العميل آخر حالة ويدمج محلياً ثم يعيد المحاولة

هذا النهج أكثر ملاءمة للتشغيل البيني: أي تطبيق يفهم JSON يمكنه قراءة قائمة المهام، حتى لو لم يفهم بنية CRDT.

التجربة الثالثة: مكالمات فيديو WebRTC عبر بروتوكول AT

التجربة الأكثر إثارة استخدمت بروتوكول AT كآلية signaling لمكالمات WebRTC. أحد الأقران يكتب سجلات ICE candidate إلى خادم PDS مع تسمية المستلم المقصود، والقرين الآخر يستمع عبر الـ Relay ويستجيب، ثم يُنشأ اتصال WebRTC مباشر بين الطرفين.

خلال العرض الحي، أجبرت ظروف شبكة Wi-Fi المؤتمر على استخدام خادم TURN للترحيل، وهو ما وصفه Lazaroff مازحاً بـ"خادم TURN للعار". لكنه اقترح أيضاً أن قنوات بيانات WebRTC يمكن أن تُكمّل بروتوكول AT بتوفير نقل فوري لتطبيقات local-first.

البنية التحتية المشتركة بدلاً من الخوادم المنعزلة

الحجة المركزية التي طرحها Lazaroff واضحة: على المطورين البناء على بنية تحتية مشتركة بدلاً من خوادم مخصصة لكل تطبيق. الخوادم يجب أن تبقى بسيطة وعامة وقابلة للاستبدال. وأشار إلى وجود مستضيفين مستقلين متعددين لخوادم PDS، و relays عامة مجانية، وجهود تجميع مدعومة من المجتمع كدلائل على أن بروتوكول AT يدعم هذا الاتجاه فعلاً.

تقديرات المجتمع تشير إلى وجود نحو 2000 خادم PDS مستقل يعمل حالياً على شبكة بروتوكول AT، مما يعني أن البنية التحتية ليست نظرية فحسب.

ما الذي يعنيه هذا للمطورين؟

الرسالة الأساسية من هذه التجارب أن بروتوكول AT ليس حكراً على الشبكات الاجتماعية. يمكن استخدامه كأساس لتطبيقات موزعة متنوعة: محررات تعاونية، تطبيقات إدارة مهام، وحتى اتصالات فيديو. المفتاح هو التفكير في PDS كطبقة تخزين ومصادقة عامة، لا كخادم Bluesky فحسب.

الأسئلة الشائعة

هل يمكن استخدام بروتوكول AT بدون Bluesky؟

نعم، بروتوكول AT مصمم كبروتوكول مفتوح مستقل عن Bluesky. يمكنك تشغيل خادم PDS خاص وبناء تطبيقات تستخدمه للتخزين والمزامنة دون أي علاقة بالشبكة الاجتماعية.

ما الفرق بين PDS وApp View في بروتوكول AT؟

خادم PDS يخزن بيانات المستخدم ويوفر المصادقة، وهو ملك للمستخدم أو يستضيفه مزود يثق به. أما App View فهو خادم خاص بالتطبيق يجمع البيانات ويعالجها، وهو الذي تقترح هذه التجارب الاستغناء عنه.

هل تطبيقات local-first على بروتوكول AT جاهزة للإنتاج؟

لا تزال في مرحلة تجريبية. التجارب الثلاث التي عُرضت هي إثبات مفهوم، والتحديات مثل التشغيل البيني والتعامل مع التعارضات لا تزال قيد الحل.

ما هي CRDT ولماذا هي مهمة لهذا النهج؟

CRDT (أنواع البيانات المكررة الخالية من التعارض) هي هياكل بيانات تسمح لعدة مستخدمين بالتعديل بشكل متزامن مع ضمان تقارب النتائج تلقائياً دون حاجة لخادم مركزي للتنسيق.

كيف يتعامل بروتوكول AT مع الاتصال في الوقت الفعلي؟

من خلال الـ Relays التي تبث التحديثات، لكن للاتصال الفوري جداً مثل الفيديو، يُستخدم بروتوكول AT فقط للـ signaling بينما يتولى WebRTC نقل البيانات الفعلي.