المطوّرين

اعمل جلسة بـ Passkey أو محفظة EIP-4361 SIWE. بعدين Kotobase بيصدر Biscuit قصير العمر مربوط بمستأجر واحد، جراف، حامل، انتهاء صلاحية، ومجموعة أذونات.

الاعتماد الأساسي للـ API هو Biscuit قصير العمر بيتصدر بس بعد توثيق Passkey أو SIWE. اطلبه للجراف والأذونات اللي محتاجها بالظبط:

POST https://auth.kotobase.net/v1/biscuit/token

{"tenantId":"...","graph":"...","permissions":["data:write"]}

استخدم قيمة التفويض الكاملة اللي بيرجعها نقطة النهاية:

Authorization: Biscuit <token>

بيفضل CACAO وبيانات الاعتماد Bearer الغامضة كطرق توافقية للهجرة بس.

مرر قيمة التفويض اللي رجعت مباشرة لـ SDK بتاع TypeScript، Python، أو PHP:

export KOTOBASE_TOKEN="Biscuit ..." && kotobase account-status

Biscuit المرفوض عمره ما بيتعاد كـ CACAO أو Bearer.

ثبت CLI بأمر واحد:

curl -fsSL https://kotobase.net/install.sh | sh

محتاج باباشكا وبيكتب بس على حسابك الخاص ~/.local.

عملاء TypeScript، Python، وPHP بيشاركوا في نفس عقدة النقل والمصادقة.

Datomic Client API، SPARQL (بما فيهم توافق مسار HTTP بتاع RDF4J)، Cypher، Gremlin، وGraphQL بيتابعوا من خلال اكتشاف القدرات الصريحة واختبارات المطابقة.

استخدم نقطة النهاية MCP على

https://kotobase.net/mcp

ضد نفس جراف المستأجر، أو شغل

kotobase mcp

عشان تطلع إعدادات العميل.

استورد أو مزامنة ثنائية الاتجاه لخزنة Obsidian مع الحفاظ على Markdown، frontmatter، و[[wikilinks]].

أياتوري هو تركيب مستوى الاستعلام اللي بيحول اكتشاف المزود وكتل IPLD الثابتة إلى إسقاط دائم وقابل للاستعلام.

اقرأ مصدر وأي بي آي أياتوري

IPNI discovery → provider block fetch → CID verification → required Arrangement ranges → persistent cursor → Datalog

الاكتشاف مجرد تلميح للمزود. أياتوري مش بيعتبره دليل على الاسترجاع، صحة CID، أو تنفيذ الاستعلام.

اعتبارًا من 30 أغسطس 2026، مسار طلب الاستعلام الإنتاجي المشترك kotobase.net متكون على ayatori.query، واسم قفل مكون الإنتاج هو ayatori.

ده تغيير في المستودع اللي بيخدم الإنتاج، مش في اللي بيحسبه: ayatori.query هو اسم مستعار على نفس الجسر. اكتشاف مزود IPNI وقراءات الكتل البعيدة الموثقة لسه مش بتتعمل على مسار الطلب.