The name is terrible. I needed something not taken.
What this is
Hrth is a federated messaging platform. End-to-end encrypted, zero server-side message storage, browser-side key management. Users are user@node.domain. Nodes discover each other through a registry, route messages between each other through consent-based networks, and that’s it. Messages exist in transit queues with TTLs. They’re not written to a database. They arrive, they’re delivered, they evaporate.
The goal isn’t to build a chat app. It’s to build a protocol. Simple enough that it becomes a default. Simple enough that anyone can run an instance on a Pi. Simple enough that families, communities, organisations can stand up their own node and own their own security.
Why this exists
Centralisation makes things easy, which is what people want. But it’s always a matter of when, not if, the platform gets turned against you. Broad-stroke moderation works in simulations, less so in the real world. When you have a billion users and an obvious need to moderate, you’re going to have problems. The strokes are too broad. The collateral is real people.
So: make something simple enough that instances can be small. A village takes care of, and polices, its own. When people know other people it’s easier to hold them accountable and call them out. Shame still works. You can’t completely exclude someone from the wider network, but you can relegate them outside the main network with enough effort. Moderation stays local, where social pressure actually functions.
It’s dangerous out in the world. People are being silenced by legitimately authoritarian regimes. We’ve let the internet become centralised for convenience and now it’s being weaponised against the people it was supposed to connect. If secure communication isn’t easy, no one will use it. So it has to be easy.
How it works
Three services:
- Chat node (FastAPI, PostgreSQL, Redis) — handles users, contacts, messages, groups, federation
- Web client (Flask) — all crypto happens in the browser. Identity keys generated via tweetnacl, encrypted with PBKDF2+AES-256-GCM, stored in IndexedDB
- Node registry (FastAPI, PostgreSQL, Redis) — directory service for node discovery, user search, prekey distribution, gossip-based sync
Encryption uses X3DH key agreement and Double Ratchet for 1:1 chats, Sender Key protocol for groups. Inter-node auth is Ed25519-signed JWTs with SHA-256+Ed25519 payload integrity. Federation routing has batch limits, priority lanes, circuit breakers, sharded WebSocket locks.
Instance owners can purge their database at will. It’s mostly metadata anyway, but even routing information could be useful to the wrong people. I wanted it removable.
Current state
Two live instances: village.hrth.chat and chatter.j4f.org.uk. Federation is partially working — messages have been sent across nodes, but it needs more work. Multi-device support needs nailing down. Mobile and desktop apps are next. The bones are there.
The protocol is what matters, not my particular app. If I make this simple enough, it can become infrastructure. Maybe passed over Meshtastic one day. It’ll be much harder to stamp out if it’s simple enough to run on a Pi.