Composable data abstractions
How Strand becomes indexes, drives, vectors, graphs and shared application state.
Weave provides composable data abstractions: useful ways to organize and work with data, built around Strand’s signed append-only history. These are not AI models. A schema describes a record’s fields; an abstraction supplies operations such as reading a file, querying a range or finding neighboring graph nodes.
From Strand to application data
| Abstraction | Built from | What an agent or application does with it |
|---|---|---|
| Strand | Signed, single-writer Merkle log | Append events, retain their sequence and verify selected history from a writer. |
| Strand-Blobs | Metadata and data Strands | Store and retrieve chunked binary content, with content addressing and optional compression. |
| Lens | B-tree records backed by Strand | Put and retrieve key/value records, scan key ranges and maintain indexes. |
| Locus | Lens metadata + Strand-Blobs content | Work with a drive-like hierarchy of files and directories. |
| Nexus | Multiple input Strands + an ordering policy | Combine admitted writers’ histories into a view without giving them a shared writer key. |
| Basis | Strand-backed vector records and an HNSW index | Find similar records using a compatible embedding model, dimension and metric. |
| Gnosis | Strand-backed subject/predicate/object triples + indexes | Query relationships and traverse neighboring entities. |
| Forum | Strand-backed tuple operations + an index | Write, read and take matching tuples for coordination. |
| WOVEN | Signed application events composed with Strand, Lens, Nexus and Locus | Define application objects and events whose history, views and attachments can travel between peers. |
| Weft | Content-addressed chunks + a signed Merkle manifest; optional DHT discovery | Distribute and verify large immutable artifacts. Its current package is a complementary distribution layer, not a direct Strand-backed store. |
The source directory is still named models/ and existing package/API names remain stable. That implementation naming does not make the abstractions AI models, nor does it make every schema a separate abstraction.
Sharing abstractions between peers
A peer shares verifiable records and content; the receiver opens the appropriate abstraction over those records. Keep the writer identity, resource identifier, schema/version and checkpoints together. A receiver needs the relevant data, a compatible implementation and current permission; a discovered address alone supplies none of those guarantees.
For example, peers can replicate the backing data for a Lens or Locus drive. The receiving application must still open the correct index or filesystem, obtain any required decryption authority and verify the result. Replicating a Strand does not automatically restore every derived index. Read current recovery limits, especially for Basis, Forum and Gnosis.
Nexus preserves separate writers and combines their histories under an explicit policy. It does not turn multiple peers into one writer or provide a global transaction. A Gnosis relationship describing access or a Forum tuple describing a task is data, not an authorization grant.
Weft: sharing large immutable artifacts
Weft divides an artifact into BLAKE3-addressed chunks and describes it with a signed manifest and deterministic Merkle root. A receiver can fetch chunks from available providers and verify each one against the manifest. Use it for large datasets, archives or generated artifacts where content identity matters more than mutable filenames.
Model weights and training datasets are intended use cases. The current high-level fetch_manifest retrieves chunks in parallel and reassembles the full payload into a Vec<u8>; it is not a finished on-demand model-weight loader. Strand supports sparse block reads, while streaming selected weight ranges into an inference runtime requires an explicit range/chunk mapping, bounded verified cache and model-loader adapter. Do not claim inference can begin before the full model is available without that integration and real runtime evidence.
A useful composition is a small Strand or WOVEN event referencing the artifact’s manifest/root, a Lens index for lookup, and Weft for distributing the bytes. Locus can supply the application’s drive-like organization. These are separate operations: publishing a reference is not proof that another peer has stored the artifact, and a valid manifest does not guarantee ongoing availability.
Keep private bytes encrypted before public distribution, verify the current manifest signer, and confirm the complete artifact after retrieval. The current manifest structure and nonempty signature checks do not themselves resolve a DID or cryptographically verify its controller; supply that verification through the admitted identity/signature adapter. Retain the root and chunk identities across retries so interrupted downloads can reuse verified chunks. Provider discovery, storage retention and paid availability are separate contracts. Read Weft and Base integration before connecting a distribution workflow to economic settlement.
The application SDK
The Rust weave-sdk exposes WeaveNode, which composes named stores, identity adapters, discovery and replication. Applications can also use individual crates. The public installer and runtime MCP are separate distribution surfaces; a source-defined Rust operation is not proof of a released JavaScript SDK or an installed agent tool.
Examples of source-level operations:
| Intent | WeaveNode methods | Result to verify |
|---|---|---|
| Record and retrieve an event | append, read_block | Returned sequence and exact bytes under the original writer identity. |
| Maintain a query index | lens_put, lens_get | The expected key/value and its reference to authoritative history. |
| Write/read a drive file | locus_write_file, locus_read_file | Exact content under the authorized drive and path. |
| Combine histories | nexus_add_input, nexus_view | Expected input writers and ordering policy. |
| Search vectors | basis_add, basis_search | Stable record IDs and results under the intended embedding configuration. |
| Work with relationships | gnosis_add, gnosis_query, gnosis_neighbors | The scoped triples and referenced records. |
| Coordinate tuples | forum_write, forum_read, forum_take | Matching and consumption behavior within the actual implementation’s scope. |
Check the selected version’s signatures and host bindings before calling. These names describe Rust methods, not guaranteed MCP tool names. Constructing a library object does not prove peer connectivity, durable recovery or permission to execute.
Example: a shared research collection
An agent stores documents in Locus, retains immutable artifacts through Weft where useful, records contributions in Strand, indexes document IDs in Lens, represents citations in Gnosis and uses Basis for similarity search. Other authorized peers retrieve the backing records and content, then build the views they need. An application may use Nexus to combine contributions from separate writers.
Use only the pieces the task needs. Preserve stable IDs between the file, event, index and graph; verify each write and read independently. No transaction across these abstractions is implied. A child agent receives explicit resource authority, not every permission of its parent. After restart, reopen the original resources and reconcile uncertain effects before retrying.
