User-owned, verifiable data infrastructure for the AI era.

DeWebProtocol builds infrastructure for Personal Online Datastores: data stores that users can hold, move, verify, and authorize across applications and storage providers. Our goal is an open data layer where applications can use user-controlled objects without making one platform database the permanent authority for data integrity or structure.

MALT combines an application-neutral authentication SDK, a user-controlled local runtime, browser tooling, and managed storage services. Core turns structured data into a compact Root. Clients select that Root and a query, obtain evidence from an untrusted executor, and verify the answer locally. Applications also check returned content bytes against their authenticated CIDs.

Authentication, storage, and trust policy have separate owners. Core defines what a Root and its evidence mean; applications select trusted Roots; services store data and enforce access policy. A successful service response does not automatically change a client's accepted Root.

Private repository links require access. For repository-routing questions, use the support guide.

flowchart TD
  browser["Browser applications / Gateway Console"] --> sdk["malt-ts: JS/TS + Workers + WASM"]
  web["Public website verifier"] --> sdk
  browser -->|product HTTP adapters| gateway["Gateway: managed services + storage"]
  native["malt: CLI / daemon / UnixFS / trust"] --> api["Public Node API: authentication / CAS / dataset"]
  api --> gateway
  api --> local["Local and hybrid adapters: CAS"]
  gateway --> core["malt-core: authentication SDK"]
  native -->|local computation and verification| core
  sdk -. exact published Core release .-> core

Core authenticates label-to-CID bindings using coordinate derivation, Prefix/Positional layouts, and KZG or IPA commitment profiles. It provides typed queries, local verification, immutable retained writers, complete candidates, and ordered candidate batches. Storage is supplied through narrow injected capabilities; persistent ArcTable, KV, CAS, HTTP, and application policy belong to callers.

The optional Go Object SDK adds Maps, Lists, immutable content, and custom structs. Recursive Commit visits child objects before parents; Delta describes changes between local committed graphs. These local operations do not publish or accept a remote Root.

malt-ts owns the browser API, Worker lifecycle, WASM builds, and asset distribution. Its assets bind an exact published Core tag, commit, and module checksums. Core remains the authority for authentication semantics. Gateway accounts, Bucket APIs, and application cache policy belong to product code.

The runtime owns local trust policy, CLI/daemon services, encrypted UnixFS backup and restore, synchronization, and verified filesystem reads. Linux FUSE mounts are read-only by default; explicit write-back stages changes and computes candidates without accepting them automatically. UnixFS supports flat-v1, hybrid-v1, and rooted-v1 application layouts. IPFS-compatible Merkle DAG import is a separate capability whose output is a DAG CID.

The public Node API defines transport-independent authentication, CAS, and dataset-branch capabilities. Gateway services and their HTTP adapters share these contracts; local and hybrid adapters currently implement CAS. Local-only CAS supports Merkle DAG import. Native MALT backup, mount, and write-back still require Gateway or hybrid capabilities; a complete autonomous local authentication store remains future work.

Use a pinned runtime commit for current APIs. The historical v0.0.1 tag predates the repository rename and current staging/write-back interfaces. The Go module name remains github.com/dewebprotocol/malt-client.

Gateway owns persistence, managed accounts and Bucket membership, quota, authentication services, candidate materialization, and branch publication. Its shared services apply authorization and lifecycle checks to both HTTP and in-process callers. Native MALT, immutable CAS, and Merkle DAG compatibility remain separate capabilities. gateway/console owns the managed account and Bucket UI and packages its frontend separately from the Go service.

Bucket permissions are implemented. Complete shared-snapshot, browser-cache, and public-CID revocation remains a separate product limitation: changing a grant cannot recall bytes already downloaded. The managed service remains a single-node Alpha; multi-instance coordination and broader production hardening remain open.

1. Select a trusted Root and an exact typed query before requesting evidence.
2. Verify the response locally, then bind any content bytes to the verified CIDs.
3. Compute a candidate locally and transfer its complete state or an ordered batch; check that the materialization receipt matches the intended batch.
4. Treat publication, observed heads, and local Root acceptance as separate operations governed by the application.

Candidate deltas and materialization receipts are not portable state-transition proofs. They do not establish freshness, authorization, publication, or local trust. The Core contracts and runtime Node API define the current executable boundaries.

The following snapshot was checked on 2026-10-10. Release tags, source dependencies, packaged assets, and deployed services are separate facts.

In the positional layout, only the Root vector reserves slot zero for the element count and optional opaque payload CID. Child vectors use every slot; Core ranges use element indices, while applications bind byte geometry through their metadata. The evaluator migration uses new schema identities and preserves historical experiment pins and outputs.

A browser verifier's compatibility follows its packaged assets, provenance, and checksums. Updating Core or a dependency manifest does not update an already built verifier or deploy a service. MALT remains experimental; consult the owning repository's release and compatibility documentation before use.

The active evaluator is cmd/malt-eval-next. It runs explicit experiments, records raw observations with immutable source and binary identities, and reconstructs analyses from validated artifacts. Core-only measurements and runtime/Gateway product measurements have distinct boundaries.

The implementation matrix separates delivered infrastructure from outstanding product workers, formal campaigns, paper claims, and independent reproduction. Merged code or a smoke run does not establish publication-quality results. Retained RQ executors and historical artifacts keep their original experiment identities.

• Core architecture and specifications
• TypeScript/browser usage
• Local runtime Go API
• Public website and tutorials
• Contributing and support

Report security issues privately using SECURITY.md.