Sequence Diagrams
Step-by-step animated flows for 23 key operations
Core Operations
Sync & Replication
Infrastructure
Group Management
Application Flows
Admin creates a new context with a generated identity, registers it in the group store, sets visibility, and publishes the operation across the network.
Client invokes a WASM method via JSON-RPC. The runtime executes it with host functions, commits state deltas, and broadcasts them to peers for convergence.
An admin creates a group invitation and delivers it out-of-band. The joiner uses the invitation to join, and their membership is propagated and verified across the network.
Two nodes exchange state hashes and DAG heads to detect divergence, then select and execute the appropriate sync protocol (Hash, Level, Snapshot, or Delta).
Client uploads a blob to the server which stores it locally and advertises via Kademlia DHT. Remote nodes discover providers and stream the blob on demand.
Admin triggers a group-level application upgrade. The new target is propagated to peers and applied to each context based on its upgrade policy (Automatic, Coordinated, or LazyOnAccess).
A group member joins a context within their group. Checks visibility, capabilities, and allowlist before generating a context identity and publishing a governance op.
HTTP authentication: how the AuthGuardLayer verifies JWT tokens from headers or query params and injects the authenticated identity into the request.
How an incoming StateDelta gossip message flows through the node: buffering during sync, key exchange, decryption, DAG ordering, application, and event emission.
A complete sync session: SyncManager opens a stream, shares keys, optionally shares blobs, then runs the selected DAG sync protocol.
How a SignedGroupOpV1 gossip message is received, verified, and applied through the governance DAG with pending queue handling.
When a GroupStateHeartbeat reveals missing DAG heads, the node opens a stream and requests the missing governance ops.
Specialized (TEE/read-only) node invitation: discovery broadcast, attestation verification, invitation exchange, and join confirmation.
When a node subscribes to a group topic, three operations fire in parallel: sync group state, broadcast aliases, and broadcast local state.
Admin creates a child group under an existing parent. The SubgroupCreated governance op is published on the parent's gossip topic so all peers learn about the hierarchy.
A ReadOnly member is added to a group. They can join contexts and read state, but any state mutations are discarded locally and rejected by remote nodes.
Admin grants capability bits to a group member via a governance operation, enabling them to perform specific actions like creating contexts or inviting members.
When a member is removed from a parent group, their ContextIdentity entries are cascaded through all descendant subgroup contexts. Child groups where they have direct membership are skipped.
A parent admin tries to join a Restricted context in a child group. The platform enforces that only direct group admins or context creators can manage allowlists and access Restricted contexts.
Developer generates a signing key, builds the WASM app, signs the manifest with JCS + SHA-256 + Ed25519, packages the .mpk bundle, and installs it on a node.
Context update with state migration: the new WASM module runs the migration function against the old state, produces new state bytes, and the context switches to the new application version.
A WASM method in Context A queues a cross-context call to Context B. After Context A commits, the node executes the target method on Context B using an owned member identity.
Two nodes concurrently edit the same document using the RGA CRDT. Each character insert generates a CharId with HLC timestamp. Both edits sync and merge deterministically.