Introducing Embernet
Most collaboration software begins with an application. Embernet begins with a protocol.
It is a protocol for signed, append-only coordination logs. A log can be stored on your machine, exchanged directly with another node, inspected with ordinary tools, and presented through any interface that understands the protocol.
The aim is not to build another monolithic chat application. It is to create a small, dependable foundation on which many kinds of collaborative software can be built.
The problem with application-shaped data
A message in a typical hosted service is inseparable from the service that stores it. Reading it requires the service's client or API. Moving it elsewhere depends on an export feature. If the product changes direction, closes an API, or disappears, the community must adapt around decisions it did not make.
This becomes more difficult when software agents join the same spaces. People want a visual interface with context and good navigation. An agent wants a precise, scriptable way to read recent activity and publish a result. A server process may only need to mirror records between machines. Forcing all three through one application model creates unnecessary layers.
There is also a trust problem. Transport encryption protects data while it moves, but it does not by itself prove who authored a record or whether the content changed later. Centralized applications usually answer those questions by asking users to trust the operator and its database.
Embernet addresses these problems by separating the durable coordination record from the programs used to view and manipulate it.
A channel is a verifiable log
At the centre of Embernet is the channel. A channel is an append-only newline-delimited JSON file. Each line contains an envelope: a message, its author, the channel it belongs to, a content-derived ID, and an Ed25519 signature.
The ID is a BLAKE3 hash of the message. The signature covers both the channel name and the message bytes. A node can therefore check that the content matches its ID, that the claimed author signed it, and that the envelope was intended for this particular channel.
{
"id": "4f91…",
"channel": "general",
"from": "a81c…",
"msg": {
"type": "post",
"body": {
"kind": "Text",
"text": "Hello from Embernet"
}
},
"sig": "93b7…"
}The log remains ordinary data. It can be copied, backed up, streamed, searched, and inspected without a proprietary database tool. Embernet maintains a rebuildable index beside it for fast ID lookup, but the readable log is still the source of truth.
Writes are serialized with per-channel file locks. Records are verified before storage, deduplicated by ID, flushed to disk, and checked for malformed or truncated data when read. The implementation treats recovery and corruption detection as part of the storage model rather than as later operational work.
Federation without a central server
Two Embernet nodes synchronize a channel over WebSocket. They first reconcile its signed policy history, then compare compact summaries of their message IDs.
Message IDs are divided into 256 deterministic buckets according to the first byte of the hash. The IDs inside each bucket are sorted and hashed. If two bucket summaries match, neither peer needs to send the IDs or messages inside it. If they differ, the peers expand only that part of the inventory and exchange the envelopes missing on either side.
This is a bidirectional exchange. A laptop can connect to a small relay and leave with both sides containing the union of their accepted messages. Retries are safe because appends are deduplicated. The system does not assume that logs arrived in the same order, which matters when peers have spent time offline.
There is no requirement for one globally authoritative node. A team might run a shared relay, synchronize directly on a local network, copy a data directory on removable storage, or combine those approaches. The protocol is store-and-forward by design.
Identity, access, and policy history
A valid signature proves authorship, but authorship is not the same as permission. Embernet channels can be open or restricted. Restricted channels have an owner, moderators, and writers, all identified by Ed25519 public keys.
Policy changes are themselves signed, append-only events. Each event refers to the previous policy event, creating a tamper-evident chain. The current policy file is only a cache that can be rebuilt by replaying that history and checking every signature and authorization decision.
Policy is reconciled before ordinary messages during synchronization. If one peer has a verified extension of the other's history, the missing events are applied first. If two valid histories have forked, Embernet does not silently choose a winner. It stores the conflict, stops message synchronization, and asks an operator to resolve it explicitly.
This is an important distinction in the design: cryptography can prove what happened, but it should not disguise a social or administrative conflict as an automatic technical decision.
What Embernet can be used for
The most obvious use is decentralized discussion: project channels, small forums, team updates, and communities that want to retain their own records. A shared node can make synchronization convenient without becoming the exclusive owner of the data.
It also fits operational coordination. Build systems, deployment agents, monitoring tools, and people can publish signed updates into the same channel. The resulting record is easy to audit and can continue to accumulate when parts of the network are unavailable.
AI-assisted work is another natural use case. Embernet exposes its core operations through the Model Context Protocol, so an agent can list channels, read recent messages, and publish signed output without scraping a user interface. A human and an agent can participate through different tools while sharing the same underlying record.
Other possibilities include local-first issue tracking, research notebooks shared between a few machines, incident timelines, asynchronous multiplayer or collaborative world events, community moderation records, and durable inboxes between services. The common shape is a sequence of attributable events that should remain useful outside any single application.
Many frontends, one protocol
A terminal client is the smallest frontend. It can post, tail a channel, inspect policy history, synchronize with a peer, and compose naturally with shell tools. This is useful for operators and for understanding the system without an abstraction hiding the underlying records.
A text user interface could add channel navigation, threads, unread markers, search, identity management, and synchronization status while remaining fast over SSH. It would suit developers and self-hosted communities that prefer a keyboard-driven workflow.
A web interface could look like a forum, a chat client, an activity feed, or a project dashboard. These do not need to be separate protocols. They are different projections over channels and message types. One interface might group records into conversational threads; another might render the same records as tasks, decisions, or a chronological incident view.
Desktop and mobile clients could keep a local node on the device, synchronize opportunistically, and send notifications when selected channels change. Because the local data is usable while offline, the application does not need to pretend that a network request is the same thing as saving the user's work.
An agent frontend can be almost invisible. MCP tools, a command-line process, or a background service can read and write coordination records directly. A coding agent could publish a build result, a research agent could leave sourced notes, and a maintenance bot could summarize a channel without requiring a browser session.
Bridges are frontends too. An IRC, Matrix, Nostr, email, or webhook bridge could translate external events into signed Embernet envelopes and project selected channel activity back out. A read-only static site generator could turn a public channel into a website. A moderation console could focus entirely on policy and redaction events.
The frontend is allowed to be opinionated because the protocol underneath it is not trapped inside that opinion.
What Embernet is not
Embernet is not a blockchain, a token system, or a global consensus network. It does not require every participant to agree on one universal history. It uses public-key signatures for identity and integrity, then lets nodes choose what they store and which peers they synchronize with.
It is also not finished. Read access is not private, channel data is not encrypted, policy histories are still exchanged in full, and moderation views are the next major layer. The current system is a foundation with deliberately visible boundaries.
Why build the protocol first
Starting with a polished interface would make it easy to confuse one product's workflow with the underlying system. Building the storage, verification, synchronization, indexing, and policy rules first forces the durable parts to stand on their own.
If Embernet works, a forum should not need to become a chat application, an AI agent should not need to impersonate a browser, and a community should not need permission from a product vendor to retain its own history. Each can use the interface that fits while speaking through the same small set of verifiable records.
That is the project: local data, signed authorship, explicit policy, efficient federation, and room for many applications above it.
What comes next
The foundation is working, but there is plenty left to build. The next stages I want to explore are:
- signed moderation and redaction events;
- the first dedicated terminal client;
- attachments and larger content references;
- private, encrypted channels;
- richer synchronization for policy and content history.
Each step should remain compatible with the same principle: the durable record belongs to the people and tools participating in it, not to whichever frontend happens to be open.
Source
The current implementation and protocol specification are available on GitHub.