Tagged: crdt
13 projects across the lattice ecosystem.
Embedded Engines
Convex Architecture Documents
- CAD000: Design Principles Codifies the non-negotiable axioms every other CAD inherits from — immutable values, bounded resources, CRDT-safe idempotence, security-first cryptography. This is the constitution: why Convex refuses the shortcuts (mutable state, unbounded ops, bespoke crypto) that trap other decentralised platforms.
- CAD002: CVM Values Mandates that every value on the network is a pure immutable cell in a Merkle DAG — so hashes are stable identities, snapshots are O(1), and untrusted smart contracts can be handed references without defensive copying. This is the data-model prerequisite for everything the lattice does that a mutable-heap blockchain like Ethereum cannot.
- CAD003: Encoding Format Defines the one canonical byte encoding every cell collapses to, so any value hashes to exactly one global ID and peers can deduplicate, stream and merge state without coordination. This is the physics of the lattice — JSON has no canonical form, Protobuf needs schemas, ASN.1 can't bound buffer size; CAD3 solves all three at once.
- CAD015: Peer Communications Defines an asynchronous, transport-agnostic message format where every payload is a CAD3 cell and branches can be omitted for deltas — so a huge state can be transmitted as a tiny diff when the receiver already holds the rest. Gossip and lattice sync ride the same efficient wire.
- CAD024: Data Lattice Specifies the off-chain CRDT substrate — content-addressed, lazily loaded, self-healing, garbage-collectable, structurally shared and JSON-superset typed. This is where Convex solves what IPFS handles clumsily: rich types, efficient deltas, and merges that just work instead of manual pinning and reconciliation.
- CAD028: Data Lattice File System A POSIX-compatible self-sovereign file system on the lattice — CRDT merge means editing the same file on two offline devices reconciles automatically, with Merkle verification and peer-to-peer sync. Dropbox/iCloud with the provider removed and the data still yours.
- CAD035: Lattice Cursors A thin mutable pointer layer over immutable lattice values — applications get atomic compareAndSet, updateAndGet, nested navigation, and sync/fork, while the underlying Merkle DAG stays pure. This is how applications use CRDT data without thinking about CRDT merges.
- CAD036: Lattice Node A lightweight non-consensus server that just replicates CRDT lattice data over the network — no CPoS, no staking, minimal resources. The right tier for CDNs, collaborative apps and hybrid dApps that need lattice sync without the cost of running a full Convex peer.
- CAD037: KV Database A Redis-style per-owner signed KV store on the lattice — multi-writer, offline-first, convergent without leader election because merge is mathematical, not negotiated. Gives hybrid dApps the shared mutable state that a global blockchain cannot afford to host.
- CAD039: Convex SQL Typed SQL tables on the lattice with Apache Calcite as the query planner — full SELECT/JOIN/aggregate over decentralised, CRDT-replicated rows. Bridges relational thinking to CRDT storage, so existing SQL tooling plugs into a decentralised backend.
- CAD040: Lattice Queue A Kafka-style append-only log on the lattice — stable offsets, independent consumer positions, CRDT-convergent replication, and truncation that preserves offset identity. Event streaming without a central broker, paired with CAD037's state to cover both halves of distributed-system data.
- CAD045: Lattice Applications A four-layer pattern (API / cursors / lattice types / node infrastructure) for decentralised apps that compose LWW, Index, Map and Set lattices into correct, signed, mergeable domain models. Turns raw CRDT primitives into a repeatable recipe, so self-sovereign apps don't each reinvent merge semantics and silently lose data.