Sam hasto go.
His mum said dinner. He has the only saved copy of your club’s note.
Six friends. One very small internet.
Let’s see who gets to keep it.
Football at four.
Bring the terrible orange ball.
Sam is hosting. Everyone else has to ask him for the note.
If Sam is the only host, the note becomes unavailable when he goes offline. If his friends have saved copies, they can keep sharing theirs. Turn on JavaScript to try it.
This is a model of saving and sharing. Sending someone home disconnects them; it does not erase their copy. Tap a friend to send them home or bring them back.
How to build on this ↓The internet could have more than one home.
A group chat. Your friends’ photographs. The local jokes that make no sense to anyone else. People could keep copies on their own devices and exchange what they’re missing.
A friend leaving would be an ordinary event. Someone else could still have the note.
The title is an ambition. There would still be computers, network providers, and sometimes relay servers. The useful thing to remove is the one indispensable owner.
Save your game.
A saved game stays on your computer after you stop playing. Give a post that same ordinary privilege. Save it locally before trying to send it anywhere.
In the starter, each tab keeps a separate collection in IndexedDB, the browser’s built-in database. Reopening that same replica loads what it saved. Browser storage can still be cleared or lost, so a real app also needs export and backup.
The browser already has a database ↗Trade your doubles.
“I’ve got 12, 14 and 18. Which ones are you missing?” You’ve done the hard part of understanding sync if you’ve ever swapped stickers.
Give each signed post a stable ID. Exchange ID lists, request missing posts, verify them, then save. Ignore repeats. Start with posts you can only add. Editing the same text on two offline devices needs a merge rule; a library such as Automerge can help with that later.
An example for merging concurrent edits ↗Pass a locked note.
Imagine a little box whose keys belong to your friends. Someone can carry the box without being able to open it. A signature lets the others check which key signed the note.
The starter uses the browser’s Web Crypto API for AES-GCM encryption and ECDSA signatures. It gives every encrypted post a fresh nonce. These are real operations, but assembling them is only a learning exercise. Shared keys, membership changes and device loss need much more care in a real group.
Use cryptography that already exists ↗Let somebody go home.
Close the tab that wrote the note. Ask another friend for it. Bring the first friend back. Give them the things they missed. That is a much better test than drawing a lot of connected dots.
The starter’s tabs talk through BroadcastChannel on one browser and one origin. Across computers, you need peer discovery and a transport. Direct connections can fail behind routers and firewalls. A relay may be needed to carry encrypted traffic.
What connecting actual browsers involves ↗Three tabs.
A tiny beginning.
There’s a working version you can open, read and take apart. Write a note in one tab. Watch another save it. Close the first. The copy stays.
It includes encrypted notes, signatures, saved copies and catching up after a tab reconnects.
A learning demo in one browser, on one device. Use made-up notes. The tabs share an origin and a browser profile, so they are not a security boundary. This is not a deployed social network.
Or run it on your own computer.
- Download the source and unzip it. You’ll need Python 3 and a recent browser.
- Open a terminal in the unzipped
starterfolder.On Windows, you may needpython3 -m http.server 8787 --bind 127.0.0.1py -3in place ofpython3. - Open localhost:8787. Use the starter’s invitation to open the other tabs in the same browser profile.
- Write a note. Let the other tabs save it. Close the author’s tab and read the surviving copy.
Python serves the files. The tabs exchange notes inside the browser. Leave the terminal open so you can load or reload the page.
Then try it outside the living room.
The basic moves fit on this page. Making them dependable for people takes longer. These are the next problems to tackle, with tools you can inspect.
Two friends on two different computers
Keep the local database and the signed event format. Replace the tab channel with a network transport. First connect two processes on one machine, then two computers on a LAN, then two different home networks. Test each transition before adding anything else.
libp2p’s browser connectivity guide describes one available approach. Browser connections may need rendezvous, hole punching and relay infrastructure. Run more than one independently operated relay if one relay’s disappearance must not stop everyone. Encryption does not conceal all IP addresses, traffic timing or relationships.
Someone goes offline before their friends arrive
A post cannot travel from a sleeping phone. At least one reachable device must have saved it. Ask peers to acknowledge storage, count those acknowledgements, and distinguish “saved here” from “saved elsewhere” in the interface. Test losing one replica, several replicas and every online replica.
A community might volunteer a few computers that stay on. They are servers, even if they belong to friends. Their copies can improve availability, but their disks, bandwidth and upkeep cost something. Choose a storage limit and decide who pays before promising reliable delivery.
Someone leaves the group with a key
A shared invitation key is enough to illustrate the mechanism. It is a poor long-term membership system. A person who has it can keep it. Changing the key for future posts does not erase copies or keys they already hold.
For real groups, investigate an established group encryption protocol and a maintained implementation. Messaging Layer Security, specified in RFC 9420 in 2023, is one starting point for evaluating membership changes and key updates. It still needs identity verification, device recovery, delivery infrastructure and a careful implementation. The starter does not implement MLS or forward secrecy.
Two people change the same thing
The starter adds notes. It does not edit or delete them. For a first networked version, you can keep that rule: a reply is a new signed event referring to an earlier one. There is no need to solve collaborative document editing just to send a note.
If you add edits, decide what concurrent changes mean. Automerge is an example of a library that can merge concurrent document changes. Merging data does not determine who is allowed to change it. Authorization and abuse controls remain application work.
Somebody behaves horribly
People still need block, mute and reporting tools. Devices need limits on message size, storage and traffic. A signed message identifies a signing key; it does not prove that the person using it is honest, welcome or even the person you expected.
Agree how invitations work, who can remove a member, how that decision is reviewed, and how people export their data or leave. A deletion request can hide a post in cooperating apps. It cannot force another person to erase a saved copy. Community ownership requires community decisions.
Sam can eat his dinner.
The note can wait for him.
The rest of you can keep playing.
Build something
your friends
get to keep.
Start with three tabs. Change one thing. See what survives.
Open your first little network ↗