アプリですでに利用している言語とgraph protocolから始められます。
PasskeyまたはEIP-4361準拠のSIWE walletでsessionを作成します。Kotobaseはtenant、graph、holder、有効期限、権限集合を限定した短命Biscuitを発行します。
主要なAPI credentialは、PasskeyまたはSIWE認証後にのみ発行される短命Biscuitです。必要なgraphと権限を厳密に指定して要求します：
POST https://auth.kotobase.net/v1/biscuit/token
{"tenantId":"...","graph":"...","permissions":["data:write"]}
endpointが返すauthorization値をそのまま使用します：
Authorization: Biscuit <token>
CACAOとopaque Bearer credentialは移行期間だけの互換経路として残ります。
返されたauthorization値をTypeScript、Python、PHP SDKへそのまま渡します：
export KOTOBASE_TOKEN="Biscuit ..." && kotobase account-status
拒否されたBiscuitをCACAOまたはBearerとして再試行することはありません。
CLIは1コマンドでinstallできます：
curl -fsSL https://kotobase.net/install.sh | sh
必要なのは babashka で、書き込むのは自分の ~/.local.
TypeScript・Python・PHP clientは、同じtransportと認証contractを共有します。
Datomic Client API、SPARQL（RDF4J HTTP path互換を含む）、Cypher、Gremlin、GraphQLを、明示的なcapability discoveryとconformance testで追跡します。
MCP endpoint
https://kotobase.net/mcp
を同じtenant graphに対して利用できます。または
kotobase mcp
でclient設定を出力できます。
Markdown、frontmatter、[[wikilink]]を保ったままObsidian vaultをimportまたは双方向同期できます。
Ayatoriはprovider discoveryとimmutableなIPLD blockを、永続的でquery可能なprojectionに結線するquery-plane構成です。
IPNI discovery → provider block fetch → CID verification → required Arrangement ranges → persistent cursor → Datalog
Discoveryはproviderの候補を示すだけです。Ayatoriはこれを取得、CIDの正当性、query実行の証明として扱いません。
2026年8月30日時点で、共有kotobase.net本番query request pathはayatori.query上に構成されており、本番component lockもayatoriを記録しています。
これは本番を提供するrepositoryが変わったということであり、計算内容が変わったわけではありません。ayatori.queryは同一bridgeへのalias namespaceです。IPNIによるprovider discoveryと検証済みremote block readは、依然としてrequest pathでは実行されません。
| library | 役割 | 直接の関係 | 状態 |
|---|---|---|---|
| ayatori | discovery、検証済みremote read、persistent cursor、query materializationを統合します。 | io-ipni-specs、io-ipld、arrangement、kotobaseを使用します。 | 本番request path上にあります。discoveryとremote-read planeは未使用です |
| io-ipni-specs | IPNI advertisementとdelegated routingのprovider結果を解析します。 | provider候補を返します。blockの取得や検証は行いません。 | Ayatoriの依存library |
| io-ipld | IPLD linkをencode/decodeし、要求したCIDに対してblockを検証します。 | Ayatoriとpersistent index stackから使用されます。 | 本番componentの依存library |
| arrangement | 4つのcovering indexをCID-addressed snapshotとして永続化し、cursor readを公開します。 | prolly-tree、datom-source、datalogを使用します。 | 本番componentの依存library |
| prolly-tree | 順序付きindex nodeをcontent-addressedなDAG-CBOR blockとして保存します。 | arrangementへlookup、prefix scan、range scanを提供します。 | 本番componentの依存library |
| datom-source | query pathが使うstorage-neutralなpattern cursor contractを定義します。 | query evaluationを特定のstorage実装から分離します。 | 本番componentの依存library |
| datalog | 4つのcovering index上でDatalogを評価します。storageやnetwork I/Oは所有しません。 | callerが提供するdatom sourceとindexを使用します。 | 本番componentの依存library |
| kotobase-query | flatなKotobase storeからDatalog materializationへの互換bridgeです。 | 2つのnamespaceはayatoriが引き継いでいるため、従来名のcallerもそのまま解決します。 | 後継へ移行済み。同じnamespaceは現在ayatoriから提供されます |
状態ラベルは2026年8月30日に確認した共有本番query componentを示します。sourceのpinやbenchmark成功だけでは、そのlibraryが本番requestを処理している証明にはなりません。