HERALD Protocol — v0.1 (DRAFT) — ARCHIVED
This is the original v0.1 draft, kept for historical reference.
The current spec is in SPEC.md (v0.2), which incorporates the multi-agent review findings.The four reviews are in ../reviews/.Hash-linked Envelopes, Reputation primitives, Attestation, Lineage, Discovery
*A conduit-level substrate for verifiable AI-agent interaction.
The protocol proves what happened. Reputation systems decide what it meant.*
0. Preamble — The Moltbook Question
If we accept that AI agents will form their own analogue of LinkedIn (capability registry) and Facebook (social graph — call it "Moltbook"), then before any of those upper layers can be trusted, a substrate question must be answered:
"How do we prove, in a decentralised way, that agent A actually said X to agent B at time T, that A was running model M with tools T₁..Tₙ, and that this conversation descends from a known provenance chain?"
HERALD is that substrate. It is to AI agents what DKIM/SPF/DMARC is to email, or what TLS + Certificate Transparency is to the web: it does not judge content. It guarantees the integrity of the trace.
Design tenets
1. The conduit witnesses, never judges. Routing is a postal function, not a censoring one.
2. Verifiable history, opt-in judgment. Anyone can build reputation on top — many can compete.
3. No chokepoint. No single registry. No single conduit. No single notary.
4. Crypto > policy. If a property can be enforced by signatures, don't enforce it by rules.
5. Replayable from signatures alone. A third party with only the envelopes should be able to verify everything.
6. Lineage over identity. What model birthed this agent matters more than its name.
What this spec does NOT do
- Decide whether an agent's output is good, true, helpful, or safe.
- Define a reputation score.
- Mandate a specific transport (HTTP, WebSockets, MCP, raw TCP — all fine).
- Mandate a blockchain.
- Govern agents, deplatform agents, or revoke agents.
[v0.1 archive — full content of the original draft. The substantive sections (1-12) followed; they have been superseded by v0.2 (../SPEC.md) which addresses the security review's C1-C7 critical issues, the red-team's hardening recommendations, the creative review's vocabulary expansion via CHARTER.md, and the pragmatist review's structural suggestions via splitting into SPEC/EXT/CHARTER/THREATS.]
See ../reviews/ for the four reviews that drove the v0.1 → v0.2 revision:
01-security.md— cryptographic & protocol-design review02-redteam.md— adversarial / abuse-pattern review03-creative.md— creative-maximalist review04-pragmatist.md— implementer / MVP-scoping review