سجل شفافية لعروض الإقامة الموقّعة: تاريخ ثقة يكشف أي عبث

يحتاج الحجز عبر الذكاء الاصطناعي إلى الثقة، وتاريخ الثقة الخاص بالمضيف جزء من تلك الثقة. لكن تاريخ الثقة لا قيمة له إلا إذا تعذّرت إعادة كتابته بصمت بعد وقوع الأحداث — والحفاظ على نزاهته يستدعي عادةً حارس بوابة: شركة مركزية لمنح الشهادات تحتفظ بالسجل، وتقرّر من هو في وضع جيد، وتصبح هي نفسها الوسيط الذي كان المضيفون المستقلون يحاولون تجنّبه.

وثمة طريقة أخرى. فقد أطلق HemmaBo سجل الشفافية VRP Transparency Log: سجل لا يقبل إلا الإضافة وقابل للتدقيق علنًا لعناصر Vacation Rental Protocol، لا يستطيع أحد — ولا حتى HemmaBo — إعادة كتابته دون أن يُكتشف ذلك، ويستطيع أي أحد التحقق منه دون الوثوق بالمشغّل.

ما هو سجل الشفافية

بُني السجل على شجرة Merkle وفق RFC 6962 — وهي البنية نفسها التي تؤمّن Certificate Transparency، النظام العام الذي يحافظ على نزاهة شهادات TLS على الويب. وكل إدخال هو قيمة التجزئة (hash) لعنصر VRP موقّع: عرض إقامة موقّع، أو إثبات قابل للنقل، أو حدث حالة. لا نص صريح ولا بيانات ضيوف — مجرد بصمة والترتيب الذي سُجّلت به.

ومن تلك الإدخالات ينشر السجل رأس شجرة موقّعًا: ملخصًا موجزًا وموقّعًا للتاريخ بأكمله في لحظة زمنية معيّنة.

ما الذي يُثبته

• التضمين. يستطيع أي أحد أن يطلب من السجل دليلًا على أن عنصرًا محددًا مسجَّل، ثم يعيد حساب النتيجة بنفسه للتأكد منها — دون الاعتماد على كلام HemmaBo.
• تاريخ لا يقبل إلا الإضافة. يستطيع أي أحد أن يطلب دليل اتساق بين لحظتين زمنيتين ويتحقق من أن السجل لم يفعل سوى إضافة إدخالات، ولم يُعِد كتابة إدخالات سابقة أو يحذفها قط.
• الاستقلالية. يُفحص كلا الدليلين مقابل رأس الشجرة الموقّع باستخدام مفاتيح عامة. ولا يحتاج المتحقق إلى الوثوق بالخادم الذي أنتجهما. وإذا حاول مشغّل تفريع التاريخ أو إعادة كتابته، فستفشل الأدلة.

الغاية الأساسية من HemmaBo وVacation Rental Protocol هي أن النطاق المملوك للمضيف هو مصدر الحقيقة، لا سلطة مركزية. وقد بُني سجل الشفافية للوفاء بهذا الوعد:

• إنه اختياري. يظل عرض الإقامة الموقّع بـ VRP أو الإثبات القابل للنقل قابلًا للتحقق بشكل مستقل من النطاق الخاص بالمضيف — فتوقيع النطاق ومفاتيحه كافيان. والتضمين في أي سجل ليس أبدًا شرطًا لكي تكون الإقامة حقيقية أو قابلة للحجز.
• إنه إضافي. الوجود في السجل يُثبت التسجيل والتاريخ الذي لا يقبل إلا الإضافة فقط. ولا يكون أبدًا موافقة، أو شهادة، أو ترتيبًا، أو درجة. فالسجل يقول "هذا كان موجودًا ولم تُعَد كتابته" — لا أكثر.
• إنه متعدد المشغّلين بحكم التصميم. يشغّل HemmaBo سجلًا مرجعيًا، لكن التصميم يتوقع مشغّلين كثيرين. لا يوجد سجل واحد هو الرسمي، ولا يصبح أي مشغّل حارسًا للحقيقة.

ما يرفض HemmaBo أن يصبح عليه

هذا هو الخط نفسه الذي التزمنا به منذ البداية. فلا يجوز لسجل الشفافية أن يتحوّل بصمت إلى حارس البوابة الذي جاء ليحلّ محلّه. HemmaBo ليس سجلًا للجهات المُصدِرة الموثوقة، ولا شركة لمنح الشهادات، ولا جهة تمنح الدرجات، ولا هيئة اعتماد، ولا وكالة سفر عبر الإنترنت (OTA)، ولا سوقًا إلكترونية، ولا التاجر المسجَّل (merchant of record)، ولا وسيط حجز.

لا ينبغي أبدًا أن يحتاج المضيف المستقل إلى إذن من سجل مركزي قبل أن يتمكّن نطاقه الخاص من تقديم عرض حجز مباشر قابل للتحقق — ومن توثيقه الآن توثيقًا دائمًا.

ما هو متاح الآن

النواة التشفيرية مُنفَّذة ومُختبَرة: بناء الشجرة، وإنتاج أدلة التضمين والاتساق، ورفض أي إدخال مزوَّر أو مُعاد كتابته. ويعمل السجل المرجعي على منصة HemmaBo، والعروض الموقّعة التي تقدّمها عقدة مضيف حيّة مثل villaakerlyckan.se هي تحديدًا نوع العناصر التي يسجّلها. ويستطيع أي أحد إضافة قيمة تجزئة لعنصر، وجلب الدليل، والتحقق من التوقيع ومن حسابات Merkle بنفسه.

والتصميم متحفّظ عن قصد: إثبات أن التاريخ لا يقبل إلا الإضافة وقابل للفحص بشكل مستقل، دون جعل HemmaBo مالكًا لذلك التاريخ.

يدعم سجل الشفافية الحجز المباشر المملوك للمضيف: يحتفظ المضيف بالنطاق، والعلاقة مع الضيف، والحجز؛ ويوقّع Vacation Rental Protocol العرض؛ ويجعل السجل تاريخ الثقة كاشفًا لأي عبث — دون أي شركة لمنح الشهادات في المنتصف. والمعيار هو VRP Transparency Log v0.1، المنشور مع Vacation Rental Protocol.