I'm not a developer. So I wrote a communication protocol spec.

I've been frustrated with the same problem for years.

Every important conversation ends up lost.

The bathroom renovation budget (or organize a birthday) buried in 400 WhatsApp messages. The email thread where nobody remembers
the final decision. The group chat that mixed
the project files with the birthday memes.

I'm not a developer. I'm the product person who got
frustrated enough to do something about it.

So I wrote a protocol spec.

---

The problem with email and chat

Email was designed for one-directional, asynchronous
communication. It's structured but slow, and completely
broken for collaboration.

Chat fixed the speed problem but destroyed context.
WhatsApp is fast. It's also a black hole where
everything important disappears.

Neither solves the real problem: there's no place
for a conversation that deserves context.

Not a document. Not a thread. Not a channel.
A room — convened for something specific,
with a name, with everyone involved,
with everything related to that topic in one place.

That's what I tried to spec out.

---

What is SMARD?

SMARD is an open protocol for structured communication
capsules. Apache 2.0.

The core unit is the capsule — a self-contained
JSON object that groups everything related to
a specific topic.

{
  "smard_id": "a7f3k9m2p8q1w5x6y0z3b4c8",
  "title": "Bathroom renovation — Marcos quote",
  "body": "Photos attached. Need this done before May 15th.",
  "type": "inbox",
  "status": "open",
  "author": "@alice",
  "participants": ["@alice", "@marcos"],
  "messages": [
    {
      "author": "@marcos",
      "text": "Got it. Sending the quote this afternoon.",
      "sparks": [
        { "author": "@alice", "content": "👍" }
      ]
    }
  ],
  "attachments": [
    { "type": "image", "name": "bathroom_current.jpg" }
  ],
  "tasks": [
    { "text": "Confirm final price", "done": false }
  ]
} 

That’s a complete Smard. Everything about that
renovation conversation lives in one place.
Forever. Searchable. Never lost.

The decisions that matter
No deletion. Archive only.
What was said stays said. SMARD is for
communication that must endure.
No roles. No admins.
If you received a Smard, you participate
exactly as the person who created it.
Hierarchy is not a protocol’s responsibility.
Title is mandatory.
If you don’t write one, the client suggests it
from your content. No context-free communication.
Ever.
No AI in the core.
The protocol will never depend on any AI company’s
pricing decisions. But the JSON structure is
natively readable by any LLM without
additional instructions.
That last point is intentional architecture,
not a limitation.

Four capsule types
Not everything is a conversation.

Type	Description
inbox	Communication between participants on a topic
note	Private — yours alone. A Smard you write to yourself
scheduled	Any Smard with a date and time
wallet	Documents of value: invoices, tickets, contracts

Same format. Four contexts. One protocol.

Built for today. Designed for what’s next.
Here’s something worth saying clearly:
Email protocols were designed before mobile.
Before real-time. Before AI.
SMARD is designed for the next 20 years —
including the part where AI agents act on our behalf.
When an agent buys something for you, negotiates
with a supplier, or coordinates a delivery —
that interaction needs somewhere to live.
Right now it disappears into API logs
and unstructured noise.
A Smard is the natural container for that record.
The agent writes to it. You have full context.
Nothing gets lost.
The protocol doesn’t need to change for this.
It’s already prepared.

Where we are
The capsule specification is complete and published.
SmardApp — the open-source reference client —
is in design phase. The client hasn’t been
built yet.
That’s not a weakness. That’s an invitation.
The decisions made in the next few weeks
will define the standard. The stack,
the architecture, the UX patterns —
none of it is set in stone.
This is the right moment to get involved.

What we need
If you’re a developer who wants to:
• Own the architecture of the reference client
• Contribute to a protocol designed to become
a standard
• Build something that matters beyond
the next funding round
This is for you.
Spec: github.com/smard-protocol/smard/blob/main/spec.mdRepo: github.com/smard-protocol/smardWeb: smardapp.com
Read the spec. Open an Issue.
Tell us what’s wrong with it.
We’re building this in public.
Every decision is on GitHub.
SMARD belongs to the community — not to me.

I’m Cato Sora — the product person behind SMARD.
Not a developer, but the person frustrated enough
to write a protocol spec from scratch.
Happy to answer questions in the comments.