Part 5: Channels without a platform
Post 5 of a series introducing Mesaĝkesto, a protocol for secure messaging between self-certifying identifiers.
Different types of communication
So far everything has been one person writing to another person's box. Real communication isn't only that. There are group chats, announcement lists, newsletters, team rooms, public feeds — and in every platform you've used, each of those is a separate product with its own rules, its own storage, its own idea of membership and its own way of being taken away from you.
They don't need to be. All of them are the same object, distinguished by the answers to two questions:
Who may write? and who may read?
That's it. That's the design space.
The 1:1 conversation from earlier posts is just the small case of a group with two members. Many shapes, one primitive, and no product decisions baked into the protocol.
Shape is not format
This distinction is worth pausing on, because it's where most of the intuition about "kinds of app" quietly lives. 1:1, 1:many, many:many — these describe who can do what, and nothing else. They say nothing about what the thing looks like or feels like to use. Take a single many:many channel and hand it to four different clients: one renders it as a chat with bubbles and typing dots, one as an email thread with subjects and quoted replies, one as a forum with topics and nesting, one as a timeline of short posts with likes underneath. Same channel. Same events. Same signatures. Four products. Or reverse it: a public broadcast is a newsletter if the client renders it as long-form mail, a microblog if it renders it as a stream, a status page if it renders it as incidents, a podcast feed if the entries point at audio. The author didn't choose one of those and the protocol certainly didn't. The payload types from Part 3 carry whatever structure a message has — a subject line, a threading pointer, a reaction, an attachment reference — and clients that understand a structure render it, while clients that don't ignore it and still show the message.
And the box is indifferent to all of it. It doesn't know whether it's carrying a chat, a mailing list, a forum or a feed; it holds ordered, signed, unreadable envelopes and hands them to whoever is entitled to them. "Is this app a messenger or an email client?" is a question about a user interface, not about infrastructure — and today it's a question that determines which incompatible silo your conversation is trapped in, purely because each product built its own transport underneath its own presentation. Separate the two and the strange consequence is that people using entirely different applications can be in the same conversation, each seeing it the way they prefer. That isn't a bridge or a compatibility layer. It's what happens when presentation is a local choice rather than a property of the network.
A channel names itself
Before anything else, a channel needs a name — and the naming problem here is the same one from Part 2, so it gets the same answer. Creating a channel is an event: who created it, when, of what kind, with what initial members. Hash that event, and the hash is the channel's identifier. No allocator, no namespace, no #general that somebody had to claim on a server somebody else runs. Two people creating channels on opposite sides of the world will never collide. And because the name is derived from the creation event, it is bound to it: nobody can claim a channel was created by someone else, at another time, with different founding members, because that would be a different hash and therefore a different channel. Now notice what this makes possible. The channel's identity has nothing to do with where it's stored. It is the same channel on any box, mirrored anywhere, moved at will — the way a book's ISBN doesn't change when you move it to another shelf. Nobody can squat it, nobody can seize it, and nobody can rename it. It is the group-conversation equivalent of not having a landlord.
Membership is a conversation, not a database row
The obvious way to run a group is a table on a server: rows of members, mutated by whoever the server decides is an admin. Here, membership changes are just more signed events in the channel: I invite her, I accept, I leave, he is now an admin, she is removed. Each is signed by its author, each is verifiable by every participant against the author's log, and the sequence of them is the membership. Which quietly changes what governance is. Moderation stops being an administrative act performed inside someone's system and becomes a verifiable record. If you were removed from a group, you can see who removed you and prove it. If someone claims they never invited a person, the invitation is signed. Nobody can silently rewrite who was in a room, because everyone holds the same signed events — including the box, which cannot forge one because it isn't holding anyone's keys.
Roles fall out the same way: the creator can appoint admins, admins can invite and remove, members can write. Ordinary permissions — with the difference that they're enforced by verification rather than by asking a server to be fair.
The relay still doesn't know who's there
Part 4 did the work here already, so this is a short section — but it's worth seeing it land. The box storing a group's messages checks a membership token. Every member derives the same token; the box tests it against the set it was given. Messages are encrypted by the members, for the members. So the box hosts a room and knows: this channel exists, it carries this much traffic, roughly this often. It does not know who is in it, what it's called, what it's for, or what anyone said. The members know all of that, because they hold the signed membership events and the keys. A group chat, with no group chat operator.
Broadcast: RSS that proves who wrote it
The one-writer shapes deserve their own attention, because they are more interesting than they look. A public broadcast is an append-only, publicly readable, signed feed. The author writes; anyone can subscribe; every reader can verify that each entry was authored by the identifier that claims it, and that the sequence hasn't been tampered with. Compare that to publishing today. On a social platform, authenticity comes from the platform: the account is verified because the operator says so, the feed is authentic because you're reading it on their website, and both guarantees vanish if you're suspended, if the company changes hands, or if it simply switches the timeline off. RSS solved the distribution half of this decades ago and never solved the authenticity half — an RSS feed is authentic because you trust the domain it came from, which Part 1 established is rented. Here the two are separate. Authenticity travels with the content: signed by a key committed to in the author's log, so a mirror, an archive, a cache or a hostile third party can hand you the feed and you can still tell it's genuine. Distribution becomes uninteresting precisely because it's untrusted — anyone can host a copy, and nobody has to be believed. Which means an archive is a first-class thing again. A public channel can be mirrored, indexed and preserved by anyone who cares, and the mirror is as verifiable as the original. Publications that vanish when a company pivots are not an inevitable feature of digital media; they're a consequence of letting the publisher and the platform be the same entity. A private broadcast is the same object with a reader set: an announcement list, a paid newsletter, a customer notification stream. One writer, encrypted for named readers, and — from the box's point of view — a channel with more subscribers than writers and nothing legible in it.
What's hard about this
Group encryption is genuinely difficult. Encrypting for a moving set of people, so that someone removed stops being able to read, and someone added doesn't get the last two years, is one of the more demanding problems in applied cryptography. It's the clients' job, it's solvable with well-studied designs, and it is the part where implementations most often go wrong. The protocol keeps it at the edge deliberately; it doesn't make it easy.
Removal has limits. You can rotate keys so a removed member reads nothing further. You cannot un-send what they already have. That's not a flaw in the design — it's true of every conversation, including the ones held out loud — but it needs saying, because interfaces routinely imply otherwise.
Concurrency is real. Two admins acting at the same moment — one invites, one removes, both offline from each other — is not an edge case in a system with no central sequencer. There has to be a rule that gets everyone to the same answer without a coordinator, and there is; it's the subject of the next post.
Public means public. A broadcast feed leaks by design: readers, timing, subscriber counts, and everything in the content. That's the deal you signed up for when you decided to publish. It's worth being explicit, because "encrypted messenger" and "public feed" living in the same protocol invites the assumption that everything inherits the same privacy. It doesn't, and it shouldn't.
Moderation at scale is unsolved here. A verifiable record of who did what is a much better substrate than an opaque admin panel — but nobody should pretend that spam, abuse and brigading are handled by having good logs. This is an open problem in every decentralised system, and honestly stating that is better than the usual gesture at "community governance".
Where we are
Five posts in, we have: names nobody issued, a box that holds and orders messages without reading them, permission without identification, and now every social shape communication takes — 1:1, group, announcement, public feed — built from the same signed events, hosted by infrastructure that knows almost nothing about any of it.
One question is conspicuously unanswered. Everything so far has quietly assumed both parties keep their boxes in the same place. What happens when they don't?
Next: Federation you don't have to configure — why routing between boxes needs no server list, no application to join, and no agreement between operators.
