Store, then forward.

01Software you owned

In the desktop era you installed a mail client and a newsreader, and you chose them. Somewhere else, a server run by your ISP, your university or a stranger with a spare machine accepted messages on your behalf and held them until your client came to collect. Nobody had to be online at the same time as anybody else.

That arrangement has a name: store-and-forward. It is why email still works between every provider on earth, and why a single newsgroup could have readers on thousands of different servers. Nobody owned the network. Everybody owned their piece of it.

The protocol was the product. The server was a utility. The client was yours.

02The platform ate the protocol

Then the client moved into the browser, the server moved into one company’s data centre, and the protocol vanished between them. Messaging stopped being a standard and became an app. You can’t choose your client, you can’t take your history with you, and you can’t run your own server.

None of this happened because the old model failed. It happened because the platform model is easier to build, easier to monetise and easier to control. The cost shows up later, when you want to leave.

03Pure peer-to-peer is not enough

Peer-to-peer networking promised the way back: devices talking directly, with no one in the middle. libp2p made that practical. But pure peer-to-peer has a basic problem that email solved forty years ago. Two devices can only talk while both are awake, reachable and online. Phones sleep. Laptops close. The person you are writing to is, most of the time, not there.

Every peer-to-peer application eventually needs somewhere to leave a message. The question is whether that somewhere becomes a platform again.

04What store-and-forward got right

A mail server is a modest thing. It holds messages for people who are away and hands them over when they return. It does not decide who you may talk to, rank what you see or keep you on the site. If it disappears, you point your client at another one. It is infrastructure in the plain sense: necessary, replaceable and boring.

go-ricochet is that kind of server for libp2p. It keeps mailboxes, documents and feeds for peers that are offline, pushes a notification when they come back, and otherwise stays out of the way. Its parts are named after their email ancestors, submission, transfer, delivery and access agents, because the design is deliberately the same.

05What we fixed

The old servers had real weaknesses, and some of them are why the platforms won. Ricochet keeps the shape and changes the parts that aged badly.

A ricochet node also does the work a peer-to-peer network needs from public infrastructure: it is a circuit relay for peers behind NAT, a DHT server for peer routing, and a GossipSub host that can carry topics for applications that have no servers of their own.

06Principles

1. Servers are replaceable. A client lists several in priority order and moves on when one is unreachable. How failover works
2. Identity belongs to the peer. Every access check uses the identity the connection proved, never one the request claims. Identity keys
3. The envelope is visible, the payload is not. We say exactly what the server can and cannot see. Who can read what
4. Rich software at the edges. The intelligence lives in the applications people choose. The middle stays plain.
5. Honest limits. No forward secrecy by default, no anonymity, and per-peer quotas that share capacity rather than stop abuse. We tell you up front. Encryption

07Who this is not for

If you want a global social network with one inbox for everyone, a ranking algorithm and a moderation team, build it somewhere else. Ricochet has no accounts, no global index and no feed. It is plumbing for software that people choose and own, between peers who know each other’s keys.

If that sounds like the internet you remember, or the one you wish you had, welcome.