Les détails techniques, les documents juridiques et certaines procédures de compte restent en anglais.
Commencez avec le protocole de langage et de graphe que votre application utilise déjà.
Créez une session avec un Passkey ou un portefeuille EIP-4361 SIWE. Kotobase émet alors un Biscuit à courte durée de vie contraint à un seul locataire, graphe, détenteur, expiration et ensemble d'autorisations.
La principale information d'identification API est un Biscuit à courte durée de vie émis uniquement après authentification Passkey ou SIWE. Demandez-le pour le graphe et les permissions exacts dont vous avez besoin :
POST https://auth.kotobase.net/v1/biscuit/token
{"tenantId":"...","graph":"...","permissions":["data:write"]}
Utilisez la valeur complète d'autorisation retournée par le point de terminaison :
Authorization: Biscuit <token>
Les identifiants CACAO et Bearer opaques restent des chemins de compatibilité uniquement pour la migration.
Passez la valeur d'autorisation retournée directement au SDK TypeScript, Python ou PHP :
export KOTOBASE_TOKEN="Biscuit ..." && kotobase account-status
Un Biscuit rejeté n'est jamais retenté en tant que CACAO ou Bearer.
Installez le CLI en une seule commande :
curl -fsSL https://kotobase.net/install.sh | sh
Il nécessite babashka et n'écrit que dans votre propre ~/.local.
Les clients TypeScript, Python et PHP partagent un même contrat de transport et d'authentification.
Datomic Client API, SPARQL (y compris la compatibilité du chemin HTTP RDF4J), Cypher, Gremlin et GraphQL sont suivis via une découverte explicite des capacités et des tests de conformité.
Utilisez le point de terminaison MCP à
https://kotobase.net/mcp
contre le même graphe locataire, ou exécutez
kotobase mcp
pour émettre la configuration client.
Importez ou synchronisez bidirectionnellement un coffre Obsidian tout en préservant Markdown, frontmatter et [[wikilinks]].
Ayatori est la composition du plan de requête qui transforme la découverte de fournisseur et les blocs IPLD immuables en une projection persistante et interrogeable.
IPNI discovery → provider block fetch → CID verification → required Arrangement ranges → persistent cursor → Datalog
La découverte n'est qu'un indice de fournisseur. Ayatori ne la considère pas comme une preuve de récupération, de validité de CID ou d'exécution de requête.
Au 30 août 2026, le chemin de requête de production partagé kotobase.net est composé sur ayatori.query, et le nom du verrou du composant de production est ayatori.
C'est un changement du dépôt qui sert la production, pas de ce qu'il calcule : ayatori.query est un espace de noms alias sur le même pont. La découverte de fournisseur IPNI et les lectures vérifiées de blocs distants ne sont toujours pas effectuées sur le chemin de requête.
| Bibliothèque | Responsabilité | Relation directe | Statut |
|---|---|---|---|
| ayatori | Coordonne la découverte, les lectures distantes vérifiées, les curseurs persistants et la matérialisation des requêtes. | Utilise io-ipni-specs, io-ipld, arrangement et kotobase. | Sur le chemin de requête de production ; ses plans de découverte et de lecture distante ne le sont pas |
| io-ipni-specs | Analyse les annonces IPNI et les résultats des fournisseurs de routage délégué. | Retourne des candidats fournisseurs ; il ne récupère ni ne vérifie les blocs. | Dépendance d'Ayatori |
| io-ipld | Encode et décode les liens IPLD et vérifie les blocs par rapport aux CIDs demandés. | Utilisé par Ayatori et la pile d'index persistante. | Dépendance du composant de production |
| arrangement | Persiste quatre index couvrants en tant que snapshots adressés par CID et expose les lectures de curseurs. | Utilise prolly-tree, datom-source et datalog. | Dépendance du composant de production |
| prolly-tree | Stocke les nœuds d'index ordonnés en tant que blocs DAG-CBOR adressés par contenu. | Fournit recherche, balayage par préfixe et balayage par plage à arrangement. | Dépendance du composant de production |
| datom-source | Définit le contrat du curseur de modèle indépendant du stockage utilisé par les chemins de requête. | Sépare l'évaluation des requêtes d'une implémentation de stockage particulière. | Dépendance du composant de production |
| datalog | Évalue Datalog sur quatre index couvrants ; il ne possède aucun stockage ni E/S réseau. | Consomme des sources de datoms et des index fournis par l'appelant. | Dépendance du composant de production |
| kotobase-query | Pont de compatibilité entre le magasin plat Kotobase et la matérialisation Datalog. | Ses deux espaces de noms sont portés par ayatori, donc les appelants qui les nomment encore continuent de résoudre. | Supplanté ; les mêmes espaces de noms sont maintenant fournis par ayatori |
Les étiquettes de statut décrivent les composants de requête de production partagés inspectés le 30 août 2026. Un pin source ou un benchmark réussi ne prouve pas à lui seul qu'une bibliothèque sert des requêtes en production.