يُعد ADAMANT IPFS Node v0.1.0 أول إصدار رسمي وصورة حاوية منشورة لخدمة توصيل الملفات ذاتية الاستضافة من ADAMANT. يجمع هذا الإصدار بين عنونة المحتوى، وواجهة برمجة تطبيقات REST، والتوصيل المباشر (peer-to-peer) الخاضع للتحكم، وسياسات التخزين، والنسخ المتماثل، والإصلاح، ونقاط فحص الحالة في تطبيق Node.js واحد. يستخدم ADAMANT Messenger هذه البنية التحتية بالفعل للمرفقات؛ ويهدف هذا الإصدار إلى تسهيل تقييمها ونشرها وتكييفها للمطورين الآخرين.
الملفات المملوكة للتطبيق
يبدأ التكامل بإجراءين: رفع ملف عبر POST /api/file/upload ثم استرجاعه عبر GET /api/file/:cid. يُشتق معرف المحتوى (CID) المُعاد من المحتوى نفسه بدلاً من عنوان الخادم، مما يسمح للتطبيق بتمرير هذا المعرف إلى المستلم دون الحاجة إلى تحديد الجهاز الذي يجب أن يخدم الملف. يمكن للعقدة بث نسختها المحلية أو استرداد المحتوى من الأقران (peers) المكونين الذين يفترض بهم الاحتفاظ به.
يتناسب هذا مع مرفقات المراسلة، ووسائط التطبيقات غير القابلة للتغيير، والخدمات التي يتبادل عملاؤها بالفعل معرفات المحتوى. في ADAMANT Messenger، يقوم العميل برفع مرفق مشفر، ويحمل CID الخاص به داخل الرسالة، ويقوم المستلم بجلبه من خلال عقدته. يقع التشفير ضمن بروتوكول العميل؛ بينما تتعامل خدمة التخزين فقط مع البيانات الثنائية التي تتلقاها.
شبكة ذات قواعد تشغيل صريحة
تم بناء العقدة مباشرة باستخدام Helia و libp2p. وهي تشغل حزمة IPFS مدمجة بجانب واجهة HTTP الخاصة بها، باستخدام نقل TCP، وتشفير Noise لاتصالات الأقران، وتعدد إرسال التدفقات عبر Yamux.
يقوم المشغلون بتهيئة مجموعة الأقران. يقوم تجزئة Rendezvous بترتيب الحاملين لكل CID، بحيث تستنتج العقد ذات العضوية المتطابقة نفس التنسيق. تتيح المستويات القائمة على العمر للنشر تقليل العدد المستهدف للنسخ مع تقادم الملف. يتحقق دورة إصلاح قابلة للاستئناف من النسخ المفقودة وتحاول استعادة التنسيق المقصود عندما يظل المحتوى قابلاً للاسترداد. يجمع هذا بين التنسيق والإصلاح والخدمة التي تتلقى الملفات وتسلمها، مما يلغي الحاجة إلى خدمة تنسيق تثبيت (pin-orchestration) منفصلة عند البناء حول مجموعة معروفة ومكونة بشكل متبادل من العقد.
دورة حياة الإصدار v0.1.0 في لمحة: الاستيعاب، والتنسيق الحتمي، والإصلاح والاسترجاع، مع حدود التخزين وتقارير الحالة طوال العملية.
الأقراص المحدودة تستحق سياسة حقيقية
تعد عناصر التحكم في التخزين جزءاً من مسار الاستيعاب. تساعد احتياطيات القرص، وحدود الطلبات الإجمالية، وحدود الملفات، وقبول النقل المتزامن العقدة على رفض العمل الذي لا يمكنها قبوله بأمان. يمكن أن تنتهي صلاحية الرفوعات المؤقتة الاختيارية بعد فترة TTL؛ ويستخدم جمع القمامة (garbage collection) علامات مائية وسجل دورة الحياة لاستعادة البيانات المؤهلة.
يظل المحتوى المؤكد محمياً. عندما تشغل الملفات المؤكدة السعة المتاحة، تصبح حدود القبول مهمة: التخزين المحدود لا يعني حذف الملفات التي تفرض السياسة بقاءها بشكل دائم بصمت. يختار المشغلون سياسة الاحتفاظ والنسخ المتماثل، ويوفرون السعة، ويراقبون النتائج. يمكن فحص سلوك التخزين وتهيئته، بما في ذلك ما يحدث عندما تنفد مساحة النشر.
الموثوقية تتجاوز الاتصال المفتوح
يتضمن الإصدار إصلاحات لفشل خفي في الشبكة: يمكن أن يظل اتصال TCP موجوداً بينما تتوقف تدفقات التطبيق عن العمل. كان منطق التناظر السابق قد يرى نظيراً متصلاً ويترك الجلسة المتوقفة دون مساس. يضيف PR #40 فحوصات الحيوية واستعادة الجلسة التفاعلية. ويعزز PR #42 هذا المسار بشكل أكبر: يتم دمج عمليات الاستعادة المتزامنة، ويمكن للتدفقات الفاشلة أن تؤدي إلى إعادة تعيين دون أن يتم نقضها بواسطة اختبار ping ناجح، ويمكن للتنسيق إعادة المحاولة مرة واحدة على اتصال جديد.
تتبع تقارير الحالة نفس المبدأ. تعرض GET /api/node/health حالات البدء، أو الجاهزية، أو الركود، أو التدهور، جنباً إلى جنب مع ارتفاع نقطة فحص مستمر ومعلومات العضوية. يتقدم الارتفاع عند اجتياز الفحوصات المطلوبة ويتجمد عند فشلها؛ ولا يمكن مقارنة الارتفاعات إلا ضمن نفس إصدار العضوية. يجب على المشغلين قراءة تلك الحالة، وعدم الاعتماد فقط على HTTP 200. يمكن لسماحية تراكم الإصلاح الاختيارية تحمل عدد معين من دورات الإصلاح غير الناجحة، بينما تظل نتائج التراكم والدورة مرئية للمراقبة. الإعداد الافتراضي لا يمنح أي سماحية.
تكامل سطح المكتب وعميل Tor
يتضمن v0.1.0 عمل CORS الذي يسمح للمشغلين بالسماح صراحةً بأصل سطح المكتب app://. وأصول onion المناسبة، بما في ذلك أصل null غير الشفاف الذي ترسله بعض طلبات متصفح Tor. تتضمن إخفاقات الرفع والقبول الآن رموز خطأ ثابتة يمكن قراءتها آلياً، مما يسمح للعملاء بالتمييز بين تحديد المعدل، وحدود التزامن، وعدم كفاية التخزين، وإخفاقات نصاب النسخ المتماثل، والمهلات دون تحليل النص. يظل CORS عنصر تحكم في توافق المتصفح؛ ولا تزال عمليات النشر بحاجة إلى سياسة التفويض والتعرض المناسبة لتطبيقها.
النشر
الحاوية العامة متاحة لـ linux/amd64 و linux/arm64:
docker pull ghcr.io/adamant-im/ipfs-node:0.1.0تعمل الصورة كمستخدم غير متميز وتحمل SBOM وتوثيق مصدر البناء. يتم تثبيت التكوين بشكل منفصل في /app/config.json5. يحمل مجلد /data واحد مخزن الكتل، ومخزن البيانات، وهوية النظير، ومجموعة التثبيت، وسجل دورة الحياة، ومؤشر الإصلاح، ونقطة فحص الحالة، مما يحافظ على الحالة المستمرة عبر استبدال الحاوية. يقوم خط أنابيب الإصدار بإعادة سحب واختبار كلا البنيتين، وممارسة بدء التشغيل، والجاهزية، والرفع والتنزيل، والإغلاق النظيف، والحفاظ على المحتوى وهوية النظير عبر الاستبدال.
للتقييم، ابدأ بـ docker/config.example.json5 الذي لا ينضم إلى أي شبكة. يحتوي قالب الإنتاج على قائمة أقران ADAMANT؛ يجب أن يحدد نشرك الخاص أقرانه وأصول المتصفح الخاصة به. احتفظ بخدمة HTTP خلف وكيل عكسي HTTPS مكون بشكل صحيح.
الحدود المعمارية
يتجنب التكوين المكون إعلانات DHT العامة وتوجيه البوابة العامة، مما يقلل من التعرض العام لبيانات تعريف توجيه المحتوى. لا يجعل هذا النشر مجهولاً أو سرياً بحد ذاته. الخدمة لا تشفر الملفات المخزنة؛ الرفوعات والتنزيلات غير مصادق عليها بالتصميم. يجب على التطبيقات التي تتطلب السرية أو الوصول المصادق عليه توفير عناصر التحكم تلك فوق طبقة التخزين.
لا يوجد توافق عام مع IPFS، أو IPNS، أو بوابة عامة، أو واجهة برمجة تطبيقات متوافقة مع Kubo في هذا الإصدار. المحتوى المخزن هنا لا يتم الإعلان عنه للشبكة العامة، ولا يمكن استرداد المحتوى الذي يحتفظ به الأقران العامون فقط من خلال هذه العقدة. لا يزال الحذف الموقع من قبل الرافع، واكتشاف الأقران الديناميكي، ومحاسبة حركة المرور عملاً مفتوحاً.
بالنسبة لمجموعة أقران معروفة وتسليم تطبيقات معنونة بالمحتوى، تشكل هذه الخيارات نموذج تشغيل مركزاً. للمشاركة العامة في IPFS، أو أسطول ديناميكي، أو عناصر تحكم في الهوية والوصول على غرار S3، راجع دليل المقارنة قبل اختيار بنية التخزين.