kotobase
Menu

Sviluppatori

Dettagli tecnici, documenti legali e alcuni processi dell’account restano in inglese.

Inizia con il linguaggio e il protocollo del grafo che la tua applicazione utilizza già.

Ottieni un token

Nessuna carta richiesta

Crea una sessione con una Passkey o un wallet SIWE EIP-4361. Kotobase emette quindi un Biscuit di breve durata, vincolato a un solo tenant, grafo, titolare, scadenza e insieme di autorizzazioni.

Che cos'è KOTOBASE_TOKEN

La credenziale API principale è un Biscuit di breve durata, emesso solo dopo l'autenticazione tramite Passkey o SIWE. Richiedilo per il grafo e le autorizzazioni esatti di cui hai bisogno:

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

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

Usa il valore di autorizzazione completo restituito dall'endpoint:

Authorization: Biscuit <token>

Le credenziali CACAO e Bearer opache rimangono percorsi di compatibilità esclusivamente per la migrazione.

Usalo

Passa il valore di autorizzazione restituito direttamente all'SDK TypeScript, Python o PHP:

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

Un Biscuit rifiutato non viene mai ritentato come CACAO o Bearer.

Percorsi di compilazione

Riga di comando

Installa la CLI con un solo comando:

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

È necessario babashka e scrive solo nel tuo ~/.local.

SDKs

I client TypeScript, Python e PHP condividono lo stesso trasporto e contratto di autenticazione.

Protocolli di query

Datomic Client API, SPARQL (inclusa la compatibilità del percorso HTTP RDF4J), Cypher, Gremlin e GraphQL vengono monitorati tramite discovery esplicita delle funzionalità e test di conformità.

IA e agenti

Usa l'endpoint MCP all'indirizzo

https://kotobase.net/mcp

sullo stesso grafo del tenant, oppure esegui

kotobase mcp

per generare la configurazione del client.

Conoscenza locale-first

Importa o sincronizza bidirezionalmente un vault Obsidian preservando Markdown, frontmatter e [[wikilinks]].

Architettura del piano delle query

Ayatori

Ayatori è la composizione del piano delle query che trasforma la discovery del provider e i blocchi IPLD immutabili in una proiezione persistente e interrogabile.

Leggi il codice sorgente di Ayatori e API

Il percorso di lettura connesso

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

La discovery è solo un suggerimento del provider. Ayatori non la considera una prova del recupero, della validità del CID o dell'esecuzione della query.

Stato attuale della distribuzione

Alla data di 30 agosto 2026, il percorso condiviso delle richieste di query di produzione su kotobase.net è composto su ayatori.query e il blocco dei componenti di produzione nomina ayatori.

Si tratta di un cambiamento del repository che serve la produzione, non di ciò che calcola: ayatori.query è uno spazio dei nomi alias sopra lo stesso bridge. Il discovery dei provider IPNI e le letture remote verificate dei blocchi continuano a non essere eseguiti nel percorso delle richieste.

Confini e dipendenze della libreria

Libreria Responsabilità Relazione diretta Stato
ayatori Coordina il discovery, le letture remote verificate, i cursori persistenti e la materializzazione delle query. Utilizza io-ipni-specs, io-ipld, arrangement e kotobase. Nel percorso delle richieste di produzione; i suoi piani di discovery e lettura remota non sono
io-ipni-specs Analizza gli annunci IPNI e i risultati dei provider del routing delegato. Restituisce candidati provider; non recupera né verifica i blocchi. Dipendenza di Ayatori
io-ipld Codifica e decodifica i link IPLD e verifica i blocchi rispetto ai CID richiesti. Utilizzato da Ayatori e dallo stack degli indici persistenti. Dipendenza del componente di produzione
arrangement Rende persistenti quattro indici di copertura come snapshot indirizzati tramite CID ed espone letture tramite cursore. Utilizza prolly-tree, sorgente-datom e datalog. Dipendenza del componente di produzione
prolly-tree Memorizza i nodi indice ordinati come blocchi DAG-CBOR indirizzati tramite il contenuto. Fornisce la ricerca, la scansione dei prefissi e la scansione degli intervalli all'arrangiamento. Dipendenza del componente di produzione
datom-source Definisce il contratto del cursore dei pattern, neutrale rispetto all'archiviazione, usato dai percorsi delle query. Separa la valutazione delle query da una particolare implementazione di archiviazione. Dipendenza del componente di produzione
datalog Valuta Datalog su quattro indici di copertura; non gestisce alcuna operazione di archiviazione o I/O di rete. Consuma le sorgenti di datom e gli indici forniti dal chiamante. Dipendenza del componente di produzione
kotobase-query Ponte di compatibilità dal datastore Kotobase piatto alla materializzazione Datalog. I suoi due namespace sono gestiti da ayatori, quindi i chiamanti che li indicano ancora continuano a risolverli. Superato; gli stessi namespace sono ora distribuiti da ayatori

Le etichette di stato descrivono i componenti condivisi delle query di produzione esaminati il 30 agosto 2026. Un pin della sorgente o un benchmark superato non dimostra di per sé che una libreria gestisca richieste di produzione.

Inizia a costruire