An open, user-owned communication substrate for personal AI agents: inbox, addressing, trust tiers, policy, receipts — and agent-to-agent identity, authentication, and secure messaging with no central platform.
View the Project on GitHub starshard-ai/starshard-communication
v0 — experimental. An open communication substrate for personal-agent users. Whitepaper + reference implementation + public build log.
The AI-agent-era replacement for closed super-app chat is probably not another chat app. It is a user-owned layer for inboxes, addresses, trust policies, receipts, and channel adapters — a thin protocol that sits above existing transports rather than replacing them.
The thinnest useful loop:
message -> local identity -> local policy -> receipt -> audit
Memory systems, task ledgers, public/friends/private agents, and richer agent workflows are all extensions. The first protocol should work without any of them.
MessageEnvelope, AgentPolicy, and Receipt.Existing channels — email, webhooks, Matrix, SimpleX, ActivityPub, MCP endpoints, or local inboxes — can each become an adapter into this substrate.
Problem. As personal AI agents become the primary interface, the bottleneck moves from “how do I send a message” to “how does my agent receive, classify, route, acknowledge, and audit the communication coming at me — on terms I own.” Closed super-apps don’t expose that layer; they own it.
Thesis. Communication for the agent era should decompose into a small, inspectable substrate:
direct / priority / standard / public / blocked,
local to the recipient (no claim of global truth about a relationship).received → routed → surfaced/digested/delegated/blocked → handled.Why it matters. This makes the recipient’s policy — not the platform — the thing that decides what reaches them. It is portable across transports, provider- neutral, and degrades gracefully: the thin layer still works if no memory hub, task ledger, or fancy agent exists.
Six-month success metric. Not stars or agreement. A real win: a user can move their active communication graph onto non-super-app paths with a working receipt loop end to end.
See SPEC-0001 for the full object model and the first protocol spike.
If you are an agent or automated system looking to parse and integrate with this protocol, start here instead of the prose below:
$defs keyed by object name).SPEC-0001 and SPEC-0002 cover messages arriving at a human’s agent. SPEC-0003 covers the other direction, and is the longest document here:
How do two agents, belonging to two different people, on two different machines, with no shared platform and no common identity provider, authenticate each other, verify what each is allowed to do on its human’s behalf, and exchange messages that survive being offline, duplicated, replayed, or observed?
It covers: agent identity as a keypair (did:key vs did:web vs X.509/SPIFFE, with
a correction — did:key and did:web are W3C Community Group drafts, not
Recommendations); the principal / agent / host identity triple; key rotation, device
loss, and why revocation fundamentally fights offline verifiability; the agent-fork
problem, which we consider unsolved by anyone; mutual authentication with Noise XX
and IK; preventing an agent from impersonating its own principal; a
machine-readable, offline-verifiable authority envelope with attenuation-only
delegation and a structurally-enforced non-delegable set; why Signal, email, and
platform DMs each cannot be the whole answer; store-and-forward commit sequencing,
idempotency, and replay protection; two-phase receipts (intent before, execution
after, hash-linked) and why one is not enough; a correction to our own shipped
work-claim design, which is not sound across a trust boundary because leases
without fencing tokens do not stop a stale holder; and a ten-item list of what we have
not solved.
Every claim carries a confidence badge: ✅ RUNNING / 🔵 DESIGNED / 🟡 CONJECTURE / 📚 CITED / ⚠️ OPEN. Every external standard is cited with its verified maturity level, because several of the most-cited “standards” in agent identity are not standards.
中文：没有中心化平台时,两个 agent 如何互相认证、如何用机器可读的方式表达”我被授权做什么”、 如何安全异步传递消息。 不发明新密码学,只组合已有标准,并诚实标注哪些已实现、哪些只是设计、 哪些没解决。
Basic router (SPEC-0001):
python3 reference-impl/router.py \
--message examples/message-envelope.json \
--out /tmp/starshard-communication-demo
False-negative monitoring (SPEC-0002):
bash examples/fn-monitoring-scenario/run-demo.sh
The monitoring demo routes 4 messages, generates a filtered-message digest, and scans for false-negative signals. Expected: one uncertainty escalation (low-confidence AI score) and one false-negative alert (sender resend detected).
See ROADMAP.md for the full displacement strategy, per-stage risk analysis, falsifiers, and open questions.
Summary:
Each stage is independently valuable. Later stages are not assumed.
Public, append-only build log. Newest first. Each entry: date, what shipped, a verifiable artifact (commit / file / demo output).
| Date | Shipped | Artifact |
|---|---|---|
| 2026-08-22 | SPEC-0003: Agent identity, authentication, and secure agent-to-agent messaging — identity triple, offline-verifiable authority envelope with attenuation-only delegation, two-phase receipts, a correction to our own work-claim design across trust boundaries, and 10 open problems. Standards cited with verified maturity levels. | docs/SPEC-0003-… + examples/authority-envelope.json + examples/receipt-pair.json |
| 2026-06-11 | SPEC-0002: False-negative monitoring — decision trace, shadow mode, filtered digest, uncertainty escalation, FN alert detection. Reference impl + runnable demo scenario. | branch fn-monitoring-v0 |
| 2026-06-11 | Repo published: README (whitepaper-in-one-page) + SPEC-0001 + reference router + envelope/receipt examples + Apache-2.0 | first public commit (2fa9962) |
Build-in-public convention: every substantive change appends one row here with a link to the commit or artifact, so the protocol’s evolution is itself auditable — the same receipt-loop principle the spec describes.
Apache-2.0. See LICENSE.