These notes respond to Agents and Permanent Data and come from a code-level survey of the agents server (agents/), its signed protocol, and the Onyx schema system. The short version: the client half of "permanent data" is nearly free — every client action already arrives as a signed, canonically-encoded artifact that verifies with the same primitives as documents and comments — and the most promising unification is to make session messages into ordinary Hypermedia comments.
1. What the agent server already does
Every client→server action is a single signed DAG-CBOR envelope posted to one endpoint. The envelope (SignedActionEnvelope) carries type: 'AgentsAction', the signer principal, a 64-byte Ed25519 signature, the account the action is for, an optional Capability CID + raw blob for delegation, and the action payload with a signed timestamp. It is verified server-side with the same blobs.verify() used for documents and comments, and it has a deterministic CID under blobs.encode().
The delegation story is already end-to-end: a web device key acts as a vault account via a Capability blob carried _inside the signed payload_. An archived envelope plus its capability is independently verifiable by any third party, with no server involvement.
The protocol surface is 69 actions, but only two produce durable log content: MessageSession and InvokeSessionTool. Everything else is configuration (agents, permissions, triggers, tools, memory, providers) or reads — this maps cleanly onto the migration list in the team note.
2. The gap: the server discards the one artifact worth keeping
After verifying an envelope, the server keeps only two strings — accountId and signerId — and writes a fresh, server-authored CBOR event into session_events with a random UUID. No signature, no CID, no hash chain. The durable log is a _re-narration_ of what the client said, provenance-by-assertion. The signed bytes — the exact thing a peer could later independently validate — are garbage-collected with the request.
The repo already contains the storage pattern to fix this: tool_documents stores canonical DAG-CBOR with a CID computed exactly like a Seed blob ("publishing a tool to the network later is publishing bytes that already exist"), and the event-bus design doc already proposes generalizing it into a space_documents table.
Leverage points, smallest to largest:
Minimal: retain the received request bytes and store (cid, envelope_bytes) keyed to the session event. Zero protocol change, zero client change, fully re-verifiable. It must be the _received_ bytes, not a re-encode (DAG-CBOR undefined/null normalization has bitten before).
Better: expose envelope_cid on session events so clients and peers can address log entries by content.
Structural: hoist ts from action to the envelope root so a signed action is a _literal_ Seed blob, publishable through the existing PublishBlobs path with no new encoding.
Known asymmetries that break "everything is signed": webhook trigger firings (bearer-token JSON), server→client WebSocket events (unsigned JSON), and inline attachments (the chunked-upload actions exist so each signed action stays small — each chunk envelope is itself signed and needs a home).
3. Sessions as ordinary Hypermedia comments
The strongest idea on the table: convert each session message into a full, normal HM Comment.
Comments are already everything we want session messages to become: signed permanent blobs, threaded via reply parents, targeted at a document and version, indexed, replicated, and counted by every Seed daemon on the network. Nothing new has to be invented for user messages — and for agent replies, the server _already publishes real comments_ signed by agent signing identities through its write hm:// path.
The shape this suggests:
A session is (or is anchored by) a document — under the agent's space, or the user's.
Each user message is a Comment signed by the user's key (or their delegated device key with capability — the exact mechanism comments support today).
Each agent reply is a Comment signed by the agent's signing identity.
Sub-sessions and threads use the reply-parent structure comments already have.
Attachments are IPFS links inside comment blocks — already supported.
Streaming responses stay ephemeral and server-side, exactly as the team note holds: the Comment is published when the turn completes.
What this buys: p2p collaboration over agents falls out of the existing network. Any peer can fetch, validate, and index a session the way it indexes a discussion today. The agent server stops being the source of truth for conversation history and becomes a coordinator/executor.
What it does not cover by itself: tool calls and results, approvals, and the config-plane actions (agent definitions, permissions, triggers, memory writes). Those either stay as archived signed envelopes (§2) or become new signed blob types — which is where the schema work comes in (§5).
It also raises a real transport question: does the client keep sending MessageSession envelopes with the server minting the Comment, or does the client publish the Comment blob itself with the server _observing_ it (via subscription) and reacting? The second makes the message path server-optional and network-native, but changes latency, ordering, and delivery semantics.
4. Agent-authored data and the trust model
Agent output has no client signature by nature. The machinery to sign it exists — the server mints and holds hm-account-key signing identities per agent and already signs published hypermedia with them. But a server-held key signing the log attests only "the server says so," with more ceremony. For honest-record guarantees against a _misbehaving server_, the options are roughly: a distinct operator identity countersigning, a hash-chained log whose head the client periodically countersigns, or accepting server attestation as good enough for v1. This interacts with the note's position that account signing keys stay server-private.
5. An Onyx space for the agents data schemas
The team note is explicit that formal schemas are not a prerequisite for reasoning — agreed. The proposal here is different: use Onyx as the _notation_ for the proposal itself. A schema space is simultaneously human-readable documentation (each type is a document with prose) and machine-checkable structure (each type doc carries a schemaDefinition blob), and it is always advisory — Onyx never enforces, and the daemon is schema-blind.
This works today with zero resolution-code changes. A "space" is just an account root whose document tree is type documents (schemaDefinition) plus folders (childrenSchema); cross-type references use target-typed link fields; any account's schemas resolve in-app unbundled. Two working precedents exist: the sync-onyx repo-backed pipeline (JSON + MD pairs, deterministic CIDs, lockfile abort-on-mismatch — how the onyx account itself was published) and the in-app World Builder (buildWorldPlan already solves cross-references to not-yet-published type URLs).
A particularly good fit: Onyx already supports user-defined signed blob types extending the Hypermedia envelope. The AgentsAction envelope itself, the action union, session events, agent definitions, triggers, and tool documents can all be described as Onyx types — so the schema space doubles as the protocol's public reference documentation. The natural home is a repo-backed library next to agents/protocol, so the schemas and the TypeScript types can be checked against each other in CI.
Recommended next steps
Start archiving received envelope bytes immediately — additive, no protocol change, and it captures data that can never be recovered later.
Prototype one session rendered as a document + comment thread end-to-end (agent replies via the existing comment-publishing path) to pressure-test the sessions-as-comments model.
Stand up the agents schema library as JSON + MD pairs with the sync-onyx discipline, starting with the envelope, the two log-producing actions, session events, and agent definitions.
Do you like what you are reading? Subscribe to receive updates.
Unsubscribe anytime