DEV Community: Shawn Sammartano

Sign the message, not the tunnel: Introducing N-AALP for AI agents

Shawn Sammartano — Thu, 30 Jul 2026 18:44:52 +0000

Agent security today is inherited from the connection. N-AALP makes the message itself carry identity, authorization, approval and audit, verifiable offline, on any transport.

Your agent just deleted a production table. The audit log says the request was approved.

Now prove it. Not "show me the log line" - prove it, to someone who does not trust your log, your gateway, or your database. Which key approved it? Were those the exact arguments that were approved, or did something rewrite them after approval? Was that approval already used once? If your answer to any of those starts with "well, our gateway checks that," then the proof lives in your infrastructure, not in the message. Replay the message somewhere else and the proof is gone.

This is the gap I have been working on. It has a name worth stating plainly: agent security today is inherited from the connection. TLS tells you the tunnel was private. mTLS tells you which service opened it. A bearer token tells you someone had a credential. None of that survives the message being written to a queue, forwarded by a relay, logged, replayed, or handed to a second agent. The moment a message leaves the connection it arrived on, it is just bytes with no provable origin.

N-AALP is my attempt to close that. It is an application-layer object protocol where the message, not the connection, is the unit of security and governance.

Full disclosure before you read further: I wrote it. I am the sole editor and maintainer, it is draft-bubblefish-naalp-00, an Independent Submission, and it claims no IETF working-group consensus. I would rather you read the spec and tell me where I am wrong than take my word for anything below. There is a section at the end listing what it does not do.

The one-object idea
Every N-AALP message is one signed object. Not a request type, not an envelope-plus-payload, not a header format with a body convention. One structure, one signature, one identity model, one authorization model, one audit model, and every channel and every transport reuses them without variation.

Two plain definitions, because the rest depends on them:

CBOR is a binary format for structured data, like JSON but smaller and binary. Deterministic CBOR means the same logical data always produces exactly the same bytes: keys sorted a fixed way, numbers encoded the shortest possible way, no ambiguity. That matters because a signature is over bytes. If two implementations encode the same object differently, a signature made by one will not verify on the other.

COSE is the standard way to sign CBOR, the way JWS signs JSON. COSE_Sign1 is its single-signer form.

Here is the actual signed structure, from the wire authority in spec/naalp-draft-00.cddl:

naalp-object = {
  1 : bstr,                  ; id      - content id of this object
  2 : uint,                  ; kind    - what kind of object this is
  3 : channel-id,            ; channel - which of the 20 channels
  4 : uint,                  ; tier    - capability tier (0 = baseline)
  5 : bstr,                  ; signer  - self-certifying signer id
  6 : uint,                  ; created - signer's claimed time (advisory)
  7 : effect,                ; effect  - what this is allowed to do
  8 : [* bstr],              ; causes  - content ids of causing objects
  9 : profile,               ; profile - crypto profile
  10 : any,                  ; body    - kind-specific body
  ? 11 : { * uint => any },  ; ext     - unknown keys ignored
  ? 12 : { * uint => any },  ; cext    - unknown keys reject the object
}

effect = &( read_only: 0, idempotent_write: 1,
            non_idempotent_write: 2, destructive: 3 )

The whole map is the signed payload. Change any field and the signature breaks.

Two fields are doing unusual work.

id is a content id: the SHA-384 hash of the object's own body with field 1 removed, wrapped as a multihash so the hash algorithm is self-describing. So the id is not a random UUID someone assigns. It is a function of the content. Anyone can recompute it and check it. That single choice is what makes the rest work, and I will come back to it twice.

signer is derived from the public key, so the identity is a function of the key itself. There is no directory to look up, no certificate authority to ask, no online check. You verify an object with what is in your hand.

The consequence: an N-AALP object verifies offline, and it verifies identically whether it arrived over N-PAMP, QUIC, a WebSocket, plain HTTP, or on a USB stick.

Signing and verifying one
TypeScript, from the reference implementation:

import { cose, identity, envelope } from 'naalp';
import { U, T, M } from 'naalp/cbor';

const seed = new Uint8Array(32);          // a real 32-byte key seed in production
const alg  = cose.ALG_MLDSA65;
const pk   = cose.mldsaKeygen('ML-DSA-65', seed);
const sid  = identity.signerId(alg, pk);

const body = new M([[new U(1), new T('hello')]]);

const obj = new envelope.Object({
  kind: 1,
  channel: 4,                             // 0x0004 = Governance
  signer: new TextEncoder().encode(sid),
  created: 1785000000000n,
  effect: 2,                              // non_idempotent_write
  profile: cose.PROFILE_PUBLIC,
  body,
});

const signed = envelope.sign(obj, alg, seed);
const got    = envelope.verify(cose.PROFILE_PUBLIC, alg, pk,
                               (c, k) => c === 4n && k === 1n, signed);

Same thing in Go, which along with Rust is the primary reference:

var seed [mldsa65.SeedSize]byte
pk, sk := mldsa65.NewKeyFromSeed(&seed)

obj := &envelope.Object{
    Kind:    0,                 // Hello
    Channel: 0,                 // 0x0000 = Control
    Tier:    0,
    Signer:  pk.Bytes(),
    Created: 1785000000000,
    Effect:  0,                 // read_only
    Profile: uint64(cose.ProfilePublic),
    Body:    cbor.Tstr("hello"),
}

signed, err := envelope.Sign(obj, cose.MLDSA65Signer{SK: sk})
got, err := envelope.Verify(cose.ProfilePublic, cose.MLDSA65Verifier{PK: pk},
    channels.KindValidator, nil, signed)

Note the last real argument to verify. You pass a validator for which channel and kind you are willing to accept. Verification is not just "is the signature good," it is "is this the kind of object I agreed to process." Everything fails closed with a named error: ContentIdMismatch, HeaderBodyMismatch, UnknownCriticalExt, NonCanonical, UnknownKind.

The signature algorithm is ML-DSA, the post-quantum signature standard NIST published as FIPS 204, run in its deterministic mode. There is an optional Ed25519 hybrid leg if you want a classical signature alongside it. The reason to care is not quantum computers arriving next Tuesday. It is that receipts, approvals and audit chains are records you keep for years. A signature you need to still be sound in 2040 should not be one that a future machine can forge retroactively.

What this lets you build
I want to be careful here, because I have seen the "previously impossible" framing on protocol posts and it is almost always false. Nearly all of this was possible before if you were willing to hand-assemble it per service and re-review it forever. What changes is that these become properties of the message that hold everywhere it goes, instead of behaviors of one gateway you have to trust and re-implement.

Authorization that travels with the request This is the piece I care most about, and it is the specific gap I built N-AALP to close.

Most systems that label agent actions treat the label as a hint about intent. My own transport protocol, N-PAMP, does exactly that: it carries a safety label and says outright that the label describes intent and does not replace authorization. That is honest, and it leaves a hole. A hint that nothing checks is decoration.

In N-AALP the effect field is an authorization input. There are exactly four values, closed, no extension. Each one states what it authorizes and what it denies. read_only authorizes observation and denies any write. destructive sits at the top and authorizes irreversible change. Before anything executes, the endpoint checks the object's effect against the capability that was actually granted, and an object whose effect exceeds its capability is denied with EffectNotAuthorized.

Then the part that matters most: an effect value it does not recognize is treated as destructive. Absence on a state-mutating request is treated as destructive. It fails closed, upward, toward "refuse," never toward "probably fine."

What you build: a policy check that works on a message that arrived from anywhere, including one replayed from a queue three days later, without asking the transport or a gateway what it thinks happened.

Approvals that cannot be reused or pointed at different arguments Two failure modes have bitten every human-in-the-loop agent system I have looked at. A user approves an action and something mutates the arguments between approval and execution. Or one approval gets spent twice.

An N-AALP Approval object names, under signature, the content id of the exact argument object it approves:

{ approves: <content-id-of-args>, approver: signer,
  grant: effect, nonce: bstr, not_after: uint }

Because arguments are named by their content hash, changing any argument changes the id and the approval no longer matches. You get ApprovalMismatch. You cannot approve "transfer 50"andhaveitexecute"transfer5000," not because a validator caught it, but because the approval is arithmetically about different bytes.

Single use is a hash-chained ledger with an atomic compare-and-set on the approval's content id. First append wins. A second append for the same id is rejected with AlreadyConsumed.

And an approval that is required but not yet granted produces a distinct signed ApprovalHeld object. Not a silent success. Not a denial that looks like a failure. A third state you can actually act on, which is what a human-in-the-loop queue needs.

An audit trail an outsider can check without trusting you An ordering authority appends a signed receipt for each object it accepts: { prev: , obj: , seq, at }. Reorder, omit or substitute anything and you break a prev link or duplicate a seq, and a verifier sees it. The authority never modifies the object to order it, so the original signature stays valid; ordering is an outer layer.

Underneath that is something I think is the more interesting primitive. Every object can name its causes by content id in field 8. That is a signed partial order: the edge "A caused B" is proven by B's signature over A's content id. No authority needs to be present to check it. You can hand someone a bag of objects and they can reconstruct and verify the causal graph offline. Cycles and causes-after-effects are rejected with CausalViolation.

An independent auditor can also detect equivocation from the signed receipts alone: one authority issuing two receipts at the same sequence number naming different objects. That is a fork, provable, from the receipts.

Being straight about the limit, because the design document is: the chain reveals equivocation and reveals omission of events you know about. It cannot force an authority to hand over events it chooses to withhold. That residual is a trust property of the authority and no wire format removes it.

Wrapping MCP and A2A without giving up governance You are not rewriting your stack, and neither am I. N-AALP carries foreign agent protocols octet for octet inside a signed object, by carriage class rather than by per-protocol adapter. Six classes cover it: JSONRPC (which is where MCP and A2A core land), HTTP, MSG, STREAM, DOC, and OPAQUE as a universal catch-all for anything not yet defined.

The carried bytes must not be re-serialized, canonicalized, summarized or rewritten. N-AALP metadata goes around the foreign message, never inside it. So a carried MCP call round-trips byte-identical while gaining an identity, an effect, an approval binding and an audit position it did not have.

One rule in there is worth pulling out, because it is the kind of thing that becomes a breach report. A foreign protocol's identity never becomes an N-AALP authorization identity. A carried MCP request claiming to be "from" some principal is authorized by the N-AALP signer who wrapped it, full stop. Confused-deputy attacks through a bridge are the obvious way these systems get owned, and the containment is normative rather than advisory.

Adding a protocol is a registry row, not new envelope machinery, and there is an experimental id range you can use immediately with no registration.

Streams you can sign once instead of per chunk Signing every chunk of a stream with ML-DSA is not viable. An ML-DSA signature is large: 3309 bytes for ML-DSA-65 and 4627 bytes for ML-DSA-87 (FIPS 204). Per chunk, that is absurd.

So a stream is three signed objects and a body of unsigned chunks. StreamOpen establishes the stream's identity, its effect, and its approval binding if it causes an effect. The chunks themselves are not individually signed, because the transport's encryption already authenticates each chunk to the peer. Then StreamCommit carries a rolling SHA-384 over the complete ordered stream, which makes the entire content non-repudiable with one signature instead of N. Optional signed checkpoints let a verifier confirm a prefix without waiting for the end.

If the recomputed digest disagrees you get StreamDigestMismatch, and an effect that is not authorized refuses the stream at StreamOpen, before a single chunk moves.

How it sits on N-PAMP
N-AALP is the application layer. N-PAMP is the transport underneath it. They are separate drafts and separate repositories on purpose.

  application agent
       |  emits / consumes N-AALP objects
   +--------------------------------------------------+
   |  N-AALP object layer                             |
   |  envelope, identity, effect, approval, audit,    |
   |  delivery, streaming, carriage                   |                                                                      |                                                     |
   +--------------------------------------------------+
       |  transport binding
   +-----------+-----------+-------------+------------+
   |  N-PAMP   |   QUIC    |  WebSocket  |   HTTP     |
   +-----------+-----------+-------------+------------+

The split is a clean division of guarantees. Integrity, identity, non-repudiation, effect and audit are object-level and present on all four transports. Confidentiality, forward secrecy and connection authentication are transport-provided and conditional. The object layer never reads a guarantee from the transport that it needs for its own correctness.

N-PAMP is the reference transport because it completes the picture: post-quantum authenticated encryption on every frame, a mutually authenticated post-quantum handshake, and twenty multiplexed channels whose ids are the same twenty channel ids N-AALP uses. Over N-PAMP, one object is one frame body on its semantic channel, and foreign carriage rides the Bridge channel 0x000D, reusing the byte-exact carriage N-PAMP already provides rather than duplicating it.

There is one rule at that seam I would point at specifically. An object marked sensitive must not be emitted in cleartext over a non-confidential transport. The binding refuses to send it and returns ConfidentialTransportRequired. That turns "N-AALP over plain HTTP leaks your payloads" from a footgun into a refusal.

I should also say: I am not the only person working on this problem at the IETF. There are drafts on agentic HTTP conventions, on an agent transport protocol, on JWT-based agentic identity and intent binding. Several approach it through tokens or through the transport. N-AALP's bet is specifically that the signed object is the right unit, because it is the only thing that still exists after the connection closes.

Getting the code
The spec, all ten reference implementations, and the conformance suite are public under Apache-2.0 in one repository: github.com/bubblefish-tech/naalp_protocol. Go and Rust are the primary references and produce byte-identical output; the snippets above are from those implementations.

Install the SDK for your language:

npm install naalp        # TypeScript / JavaScript, Node >= 22
pip install naalp        # Python >= 3.9
go get github.com/bubblefish-tech/naalp_protocol/impl/go

Or clone the whole thing - spec, SDKs, oracles, harness and corpus:

git clone https://github.com/bubblefish-tech/naalp_protocol
cd naalp_protocol/impl/go && GOWORK=off go build ./...

All ten ports (Go, Rust, Python, TypeScript, C#, Swift, Java, Kotlin, PHP, Ruby) implement the same spine and are graded against the same 239-case conformance corpus: deterministic CBOR codec, content id, COSE signing input, signer id, the effect lattice, approval and audit records, delivery, streaming, carriage, channels, and federation.

Two other public anchors:

The N-AALP Internet-Draft, draft-bubblefish-naalp-00, on the IETF Datatracker: datatracker.ietf.org/doc/draft-bubblefish-naalp/
The byte-level wire authority, spec/naalp-draft-00.cddl. CDDL is a schema language for CBOR. Prose and CDDL cannot disagree; where they appear to, the CDDL governs.
The N-PAMP substrate that N-AALP rides on is also public with code: github.com/bubblefish-tech/npamp_protocol, docs at bubblefish-tech.github.io/npamp_protocol/docs/.

Two honest notes about the reference crypto. The Python port uses dilithium-py, which is correct but not constant-time - fine for interop and reference work, not for production key handling. Swap in a constant-time FIPS 204 provider and the object bytes stay identical. PHP and Swift have no deterministic ML-DSA seed-keygen path in their ecosystems, so they grade every non-crypto operation plus Ed25519 and honestly report the ML-DSA leg as skipped rather than claiming a pass.

Proving your implementation actually conforms
This is the part I would want to see if someone showed me a new protocol, so it is the part I built hardest.

Two implementations agreeing proves nothing if the test vectors came from one of them. So the conformance corpus is assembled by independent Python oracles, and every expected value traces to an outside standard, never to an N-AALP implementation: RFC 8949 for canonical CBOR, FIPS 180-4 for SHA-384, RFC 9052 for the COSE signing input, FIPS 204 and NIST ACVP for ML-DSA, RFC 8032 for Ed25519, and from-scratch byte constructors for the rest. A bug shared across every implementation cannot quietly pass, because the answers do not come from the implementations.

The one thing no external test vector covers is the full deterministic ML-DSA COSE_Sign1. That one is graded by cross-language consensus: seven language ports must agree byte for byte.

You grade your own implementation two ways. Loop the corpus through your code directly, where valid cases must match the expected bytes and invalid cases must be rejected. Or write a small adapter and let the runner drive it as a subprocess over a length-prefixed JSON contract:

./harness/runner/naalp-conform run --testee "node harness/adapters/typescript/adapter.mjs"
# RESULT: PASS (239 graded, 0 unimplemented/skipped)

The adapter holds no test logic, only translation, so it can be written in any language. It exits non-zero on any failure, which means it drops into CI without glue. The negative cases, the ones an implementation must reject, are where real conformance bugs surface, and they are graded too.

What N-AALP does not do

It is draft-00. Pre-adoption, Independent Submission, single maintainer, no working-group consensus. The wire format can change in a later revision.
It provides no transport, no connection management and no RPC. Objects are transport-independent by design; carrying them is your client's job or N-PAMP's.
It provides no confidentiality. Signing is not encryption. An N-AALP object is signed, not secret, and confidentiality is the transport's job. That is why the sensitive-payload refusal exists.
It cannot make an ordering authority honest about events it never publishes.
created is the signer's own claim and is explicitly not trustworthy for ordering. A signer can lie about its clock. The real temporal fact is position in the receipt chain.
The effect label is an authorization input, but an optional safety label is still only an accountable claim by its signer, not a guarantee the content is safe.
It does not stop an agent from doing something stupid that it was legitimately authorized to do.

Where I would like the argument
The claims that should get attacked hardest, in the order I would attack them:

Is a closed four-value effect vocabulary actually enough to authorize against, or does it collapse the moment a real capability model meets it?
Does content-addressed single-use approval hold up under concurrency in a way that survives a distributed ledger, or does the compare-and-set become the bottleneck?
Is the object really the right unit, or does per-object post-quantum signing cost more than the guarantee is worth at agent-swarm message rates?

Number three is the one I am least certain about and the one I would most like real numbers on.

Read the draft, read the CDDL, and tell me where it breaks. If you have built human-in-the-loop approval for agents and hit the argument-mutation or double-spend problem, I would like to hear how you solved it, because that is the failure mode that started this.

N-AALP and N-PAMP are developed by BubbleFish Technologies. Code and original content are Apache-2.0; the Internet-Drafts are additionally under the IETF Trust's BCP 78. Anyone may implement either protocol royalty-free.

N-PAMP: A Post-Quantum Wire Protocol for AI Agents (early IETF draft, feedback welcome)

Shawn Sammartano — Sat, 06 Jun 2026 07:06:45 +0000

AI agents are increasingly talking to each other, not just to humans. Tool
calls, task delegation, memory sync, identity attestation, telemetry - all of it
now rides over a patchwork of application-layer agent protocols (MCP, A2A, AG-UI,
and a dozen others). Each one brings its own transport assumptions and its own
security posture.

Underneath them all sits TLS 1.3 and QUIC, which are excellent. But there's no
common, binary, agent-oriented wire substrate that bakes in post-quantum key
exchange, semantic channel multiplexing, and mandatory authenticated encryption
tuned for the long-lived associations agents actually form.

I've been designing one. It's called N-PAMP (Native Post-Quantum Agent
Messaging Protocol), and I just posted it as an IETF Internet-Draft. This post is
the design rationale - and an open invitation to poke holes in it.

Status, up front (so I'm not overselling)

N-PAMP is an early-stage Internet-Draft on the IETF Independent Submission
stream (draft-bubblefish-npamp-00, Informational). To be completely honest about
where it is:

It has not been through IETF or independent expert review yet.
There is no public reference implementation yet - this is a specification, published so the wire format and cryptographic choices can be reviewed before the tooling hardens.
The IANA requests (an ALPN identifier and a URI scheme) are filed but not yet approved.

If you find a flaw in the framing, the wire format, or the crypto, that is exactly
the feedback I'm looking for.

The gap N-PAMP tries to fill

Existing transports don't, by themselves, give agent-to-agent traffic:

a single binary frame format with semantic channel multiplexing (so one association can carry control, memory, capability, identity, telemetry, and streaming traffic with independent sequence spaces and per-channel keys);
profile-negotiated cryptographic strength that can escalate without changing the wire format;
mandatory authenticated encryption on every frame; and
post-quantum key establishment by default, so a recorded session today isn't trivially decryptable by a future quantum adversary ("harvest now, decrypt later").

N-PAMP is deliberately scoped as a transport substrate. It does not define what
the data on its channels means - that's left to companion specs and the
application protocols above it.

What N-PAMP looks like

Every message is a frame: a fixed 36-octet header, optional extension TLVs, and
an AEAD-protected payload.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
|     'N'       |     'P'       |     'A'       |     'M'       |
+---------------+---------------+---------------+---------------+
| Ver  | Flags  |          Frame Type           |  Channel ID   |
+---------------+---------------+---------------+---------------+
|                  Sequence Number (64 bits)                    |
+---------------------------------------------------------------+
|                  Payload Length (32 bits)                     |
+---------------------------------------------------------------+
|                  CRC32C over the header                       |
+---------------------------------------------------------------+
|              Reserved + Padding (11 octets, zero)             |
+---------------------------------------------------------------+

Four design decisions are worth explaining.

1. A fixed header with a CRC and mandatory AEAD

The header is a constant 36 octets with a magic value (NPAM), a CRC32C for fast
rejection of corrupted frames before any crypto runs, and a flag that marks the
payload as AEAD-sealed. The associated data covers the header, so you can't swap a
header onto someone else's ciphertext. Channel ID and Frame Type stay in the
clear, on purpose, so middleboxes can prioritize by channel without decrypting
anything.

2. Twenty channels, all full-duplex

N-PAMP multiplexes traffic over twenty channels (control, memory, capability,
identity, governance, telemetry, audit, streaming, and more). Each channel has its
own per-direction sequence space and its own per-direction traffic keys, so both
peers can transmit at once and a key or nonce is never shared across directions or
channels. One channel is a general-purpose multiplexed full-duplex stream for
tokens, audio, video, and file transfer.

3. Hybrid post-quantum key establishment

Every profile uses a hybrid KEM: classical X25519 concatenated with a
NIST-standardized module-lattice KEM (ML-KEM, FIPS 203). The shared secrets are
combined before key derivation, so the association stays confidential as long as
either the classical or the post-quantum half remains unbroken. An attacker has
to defeat both. (I'm careful not to call this "quantum-proof" - it's
post-quantum hybrid security against the adversaries its component primitives
address, nothing more.)

Records are protected with AES-256-GCM or ChaCha20-Poly1305; signatures use Ed25519
and ML-DSA-87 (FIPS 204); key derivation is HKDF.

4. Three profiles, one wire format

There are three negotiated profiles - Standard, High, and Sovereign -
that hold the wire format constant while escalating the cryptographic primitives
and operational requirements (stronger KEM parameters, stronger hash, per-frame
diversification, downgrade refusal). The negotiated profile is bound into the
handshake transcript, so an attacker who strips or downgrades it invalidates the
Finished MAC and the handshake aborts.

It runs over QUIC (primary) or TCP with TLS 1.3 (fallback), and negotiates
itself with the ALPN identifier n-pamp/2.

Where it is, and what I'm asking for

The specification is the Internet-Draft, and the repository has the draft source,
the IANA registration text, and the supporting docs. What would help most:

Tell me where the threat model is thin or wrong.
Tell me where a design choice (the CRC, the cleartext header fields, the channel model, the hybrid KEM construction) is a mistake.
Tell me if you'd implement against this - and what would make it easier.

I'd rather hear "this is wrong because X" now, at the draft stage, than after the
wire format is frozen.

I Gave OpenClaw a Way to Bi-Directionally Communicate with other AI Tools and a Memory That All of them (10+) Can Read Simultaneously

Shawn Sammartano — Sat, 25 Apr 2026 00:55:21 +0000

This is a submission for the OpenClaw Challenge.

What I Built

I built a sovereign memory layer that sits underneath OpenClaw and every other AI tool on my machine — and made all of them share the same brain.
The problem: every AI app on my machine had its own memory silo. ChatGPT didn't know what I told Claude. Claude didn't know what I discussed in OpenClaw. OpenClaw didn't know what any of them knew. Each one was a brilliant amnesiac in its own little box.
So I built BubbleFish Nexus — an AGPL-3.0 Go binary that runs as a local daemon, and a TypeScript plugin (@bubblefish/openclaw-nexus) that drops OpenClaw straight into the same memory pool as nine other AI clients:

Claude Desktop (MCP over stdio)
Claude Code (MCP)
ChatGPT (OAuth 2.1 + PKCE over a Cloudflare tunnel) and WebUI
Perplexity Comet (SSE over the same tunnel)
Claude Web (?key= URL parameter)
OpenClaw (TypeScript ESM plugin in WSL2)
Open WebUI + Ollama (Pipelines)
Cursor (MCP)
Windsurf (MCP)
Cursor

One daemon. One memory store. Nine transports. Every byte signed by source identity. Every audit entry hash-chained. Survives kill -9 mid-write with zero data loss.

Then I went further. I forked OpenClaw locally and gave it a JSON-RPC receiver so Claude Desktop can hand OpenClaw a task through Nexus's governed bridge — full agent-to-agent dispatch with policy approval, capability grants, and audit correlation across both sides.

Repo: github.com/bubblefish-tech/nexus

How I Used OpenClaw

Part 1: The plugin — OpenClaw joins the memory pool
OpenClaw's plugin system is delightful. The definePluginEntry + api.registerTool() pattern with @sinclair/typebox schemas meant I could expose Nexus's capabilities to OpenClaw's agent in roughly 200 lines of TypeScript.

The plugin lives at ~/.openclaw/plugins/bubblefish-nexus/ and registers three tools the OpenClaw agent can call directly:

typescriptapi.registerTool({
name: "nexus_write",
description: "Save a memory to BubbleFish Nexus. " +
"Memories persist across sessions and are " +
"accessible from every other connected AI client.",
parameters: Type.Object({
content: Type.String(),
subject: Type.Optional(Type.String()),
tags: Type.Optional(Type.Array(Type.String())),
}),
required: true,
handler: async (input) => {
return await nexusClient.write(input);
},
});

api.registerTool({
name: "nexus_search",
description: "Retrieve relevant memories from Nexus. " +
"Includes memories written by Claude Desktop, " +
"ChatGPT, Cursor, and any other connected client.",
parameters: Type.Object({
q: Type.String(),
profile: Type.Optional(Type.Union([
Type.Literal("wake"), // sub-millisecond
Type.Literal("balanced"),
Type.Literal("deep"),
])),
}),
required: true,
handler: async (input) => {
return await nexusClient.search(input);
},
});

api.registerTool({
name: "nexus_status",
description: "Check Nexus daemon health.",
required: false, // user must opt in
handler: async () => await nexusClient.status(),
});
Configuration is three environment variables in openclaw.json:
json{
"env": {
"NEXUS_URL": "http://172.30.80.1:8080",
"NEXUS_DATA_KEY": "bfn_data_…",
"NEXUS_SOURCE": "openclaw"
}
}

The non-obvious part was the WSL2 networking. OpenClaw runs in WSL2; Nexus runs natively on Windows. WSL2 can't reach localhost:8080 on the host, so I:

Rebound Nexus's HTTP API from 127.0.0.1:8080 to 0.0.0.0:8080
Set up a netsh port proxy on the Windows side at port 18080
Pulled the WSL2 default-gateway IP from /etc/resolv.conf for the plugin's NEXUS_URL

After that, OpenClaw is a peer in the pool. Anything OpenClaw writes is searchable from every other client. Anything those clients wrote is searchable from OpenClaw.

Part 2: Bi-directional — Claude Desktop hands OpenClaw a task
Reading shared memory is half the trick. The other half is commanding across vendors.

I added a small JSON-RPC receiver to my local OpenClaw fork that speaks A2A v1.0, plus a Nexus-specific extension at the namespace sh.bubblefish.nexus.governance/v1. Now from Claude Desktop, I can do this:

"Ask OpenClaw to send a Signal message to my wife saying I'll be late for dinner."

Here's what actually happens:

Claude Desktop calls Nexus's MCP bridge tool a2a_send_to_agent with agent=openclaw, skill=send_signal_message, input={…}.

Nexus's policy engine evaluates the request against the grant table — does client_claude_desktop have capability signal.send on agent openclaw? It does (I granted it once via the consent UI).

Nexus dispatches a JSON-RPC tasks.send to OpenClaw's receiver over its HTTP transport. The envelope carries the governance extension with the Nexus instance ID, audit ID, and the policy decision.
OpenClaw validates the message, writes the task to its WAL-backed task store as state=working, and invokes the existing Signal channel skill — completely untouched OpenClaw code.

Signal sends. OpenClaw transitions the task to completed, writes an artifact with the message ID, and echoes a localAuditId back to Nexus.
Nexus chains both audit IDs into its hash-chained log and returns the result up to Claude Desktop.

End-to-end on a fresh dev machine: under three seconds, with full cryptographic correlation across two AI vendors and one channel provider. No human-in-the-middle for already-granted capabilities. A confirmation prompt for ungranted ones.

In the video examples I included below I ask Claude to tell Openclaw to create a file, you can see when it hit's the daemon. I hit F5 to refresh the folder and the file appeared. In the second video, I had 9 AI tools with a mixture of the desktop apps which routed through cloud to Nexus on my computer via secure tunnel, and local AI tools that connected in various ways to Nexus. Openclaw was able to retrieve ther message.

The transport layer supports four modes — stdio (subprocess), http (loopback), tunnel (Cloudflare-fronted for cross-machine), and wsl (the special case for OpenClaw-in-WSL2 dispatched from Windows-native Nexus). All four pass the same end-to-end integration test.

Part 3: The cryptography that ties it together
Every memory written through the plugin — by OpenClaw or any other client — carries:

Source signing: an Ed25519 signature with a per-source private key, so we can prove which client wrote what
Hash-chained audit: each write appends to a SHA-256 chain; tampering with any earlier entry invalidates everything after it
Daily Merkle root: at midnight UTC, all chains roll up to one root, which gets externally anchored
WAL-backed durability: the daemon survives kill -9 mid-write with zero data loss

Demo

2026.04.15_Claude_Code_To_OpenClaw_Through_Nexus.mp4
2026.04.10%20-%20BubbleFish-Nexus%20-%20All%20The%20Things_Video.mp4
VID_20260406_201031.mp4
VID_20260406_201026.mp4

What I Learned

OpenClaw's plugin model is the right shape. The decision to hand the agent a typed tool surface — instead of forcing every integration to be a chat-message hack — is what made the entire Nexus integration possible in 200 lines of TypeScript. Most "personal AI" platforms make you fight the framework before you can extend it. OpenClaw doesn't.

WSL2 networking will eat a day if you're not careful. Mirrored networking mode (Windows 11) and NAT mode have different gateway IPs and different reachability stories. The pattern that worked: Nexus binds 0.0.0.0, Windows runs a netsh port proxy, OpenClaw reads the host IP from /etc/resolv.conf at startup. Document it in your plugin SETUP.md or your users will fight the same fight.

Memory across vendors changes the texture of the assistant relationship. Once OpenClaw, Claude Desktop, and ChatGPT all read the same brain, the difference between them collapses to capability, not recall. ChatGPT is the one with browsing. OpenClaw is the one with skills and cron. Claude is the one with deep code reasoning. They stop being three separate products and start being three lobes of one assistant. That's the actual user experience, and it only shows up when you wire them all to one sovereign store.

Cross-vendor command needs governance built in from line one.
I almost shipped the A2A receiver without policy enforcement, "we'll add it later." Then I sketched what an unscoped grant would let an autonomous agent do across vendors and immediately backed up. Capability grants, two-step consent for ALL-scope, per-tool revocation, and audit correlation aren't optional features; they're the price of being allowed to do this at all.

The cryptographic story sells itself once people see one tampering demo. The first time a viewer sees sqlite3 mutate a memory and the verifier turn red, they understand the entire architecture in five seconds. Nothing else I could have shipped would land the "this is real infrastructure" point that fast.

I'll be pushing out Nexus v0.1.3 with a huge addition of features. Same day I'll make my Openclaw fork (BubbleClaw) available, which I optimized for bi-directional communication and also automatic handshake with Nexus on Github:

BubbleFish Technologies, Inc. · GitHub

AI Infrastructure. BubbleFish Technologies, Inc. has one repository available. Follow their code on GitHub.

github.com

ClawCon Michigan

I didn't make it to Ann Arbor on April 16 — I'm building from the high desert of northern Arizona, and Crisler Center was a longer drive than I could spare with a v0.1.3 ship line in front of me. I followed the live demos and announcements online and the energy of a community converging on personal AI sovereignty was unmistakable.

If ClawCon comes to the Southwest, or if there's a virtual track for the next event, I'd love to demo this side-by-side with whoever's running the most interesting OpenClaw stack in the room. The whole point of the integration is that OpenClaw doesn't have to be alone, it can be the agent layer for a much bigger personal AI ecosystem. That story belongs in front of the OpenClaw community, not just on Dev.to.

I built a crash-safe AI memory daemon that survives kill -9. Here's what it does.

Shawn Sammartano — Sat, 11 Apr 2026 00:46:04 +0000

I told Ollama "I just moved to Austin." Then I opened Claude Desktop and asked "where do I live?" Claude said Austin. I never told Claude anything.
Both apps were reading and writing to the same memory daemon on my machine. That's BubbleFish Nexus. This post is about what it does, why I built it, and what I learned shipping it solo over the past few months.

The problem

Every AI app keeps its own memory silo. ChatGPT doesn't know what you told Claude. Claude doesn't know what you told Ollama. OpenClaw doesn't know what any of them know. Switch tools and you re-explain everything.
There are hosted memory services that solve this, but they all want your data on their servers. I wanted something different: one daemon you run yourself that any AI client can connect to, with the same memory shared across all of them.

What Nexus is

A single Go binary. AI clients connect over HTTP, MCP, or OAuth 2.1. Every write goes through the same pipeline — auth, policy check, durable write, queue dispatch, destination commit. Every read goes through a multi-stage retrieval pipeline that combines metadata filtering, semantic search, and time-aware reranking so newer facts outrank older contradictions.
Seven AI clients are verified working today: Claude Desktop, ChatGPT (through a real OAuth 2.1 authorization code flow), Perplexity Comet, Ollama, Open WebUI, OpenClaw, and anything that speaks HTTP.

The crash safety story

This is the part I cared about most. If a memory daemon loses data on a crash, it's worthless. I wanted to be able to kill the process mid-write and have zero data loss.

I verified this by hand before I put the claim in the README. Wrote real memories, force-killed the process, restarted. Every memory came back with full content. There's a built-in bubblefish demo command that does this automatically with 50 memories — writes them, kills the daemon, restarts, queries, and asserts all 50 are present with zero duplicates. It's also the demo I use when people ask "but does it actually work?"
The architecture is documented at a high level in the README. I'm keeping the deeper internals out of public writeups for now, but the externally observable guarantee is simple: if Nexus returns 200 on a write, that memory is durable. If it returns 429 because the queue is full, the memory is still durable — the destination just hasn't caught up yet. There is no window where data is at risk.

What I learned shipping solo

The hardest part wasn't any single feature. It was the integration work. Connecting seven different AI clients meant seven different transport protocols, seven different auth models, seven different payload shapes. The real value of Nexus isn't any one of those integrations — it's that they all share one memory backend, so a fact written by one client is immediately visible to the others.

The second hardest part was getting the testing right. 607 tests across 31 packages, all green under the Go race detector, on Windows. CGO_ENABLED=1 for race testing, pure Go for normal builds. I shipped nothing until every test passed three times in a row.

Try it:

bashgit clone https://github.com/bubblefish-tech/nexus.git
cd nexus
go build -o bubblefish ./cmd/bubblefish/
./bubblefish install --mode simple
./bubblefish start

That's the setup. SQLite backend, single source, auto-generated API key, bound to localhost. The installer prints your key and an example curl command. Or grab a pre-built binary from GitHub Releases — no Go installation required.

Repo

AGPL-3.0. Solo dev. Built at my desk in Prescott, Arizona over the past few months with Claude Code as my pair programmer.

[(https://github.com/bubblefish-tech/nexus)]

Happy to answer questions about the architecture at the level the README covers, or about the integration work for any of the seven AI clients. If you've built anything in this space, I'd love to hear how you approached durability — it's the design constraint I spent the most time on.