How Farder works

Who connects to whom, what a relay actually does, what happens when a piece goes offline, and which encryption sits where — in plain English first, with the technical names alongside for anyone who wants to check.

🧩 The three pieces

Everything in Farder is one of three programs. Once you know which is which, the rest of this page is about how they talk to each other.

💻

The app

What you run. It holds your identity — a private key that never leaves your machine — and does all the encrypting and decrypting. Anything sealed is sealed here, before it goes anywhere.

🏠

The server

Where a community lives: its channels, roles, history and files. It runs on somebody's machine — usually the owner's own PC, sometimes a mini PC or a rented VPS. There is no central Farder server; every community is its own.

📮

The relay

A forwarding post office. It stores nothing — no messages, no history, no accounts. It exists so that the app and the server can reach each other without either one learning the other's home address (its IP).

🔌 What happens if…

Pick a kind of server and something that goes wrong, then step through what each piece does about it. Everything below explains the same thing in more detail.

Cause and effect
Server type
What happens
💻 You 💻 A friend 📮 Relay 🏠 Host's server 🎭 Fake relay
What happens

So…

🤝 Is it peer-to-peer?

Not today, and that is partly on purpose. In a truly peer-to-peer chat your computer connects straight to every other member's computer — which means every member learns your IP address, and from it roughly where you live. Farder's members never connect to each other. They all connect to the server, which passes things along. A server can be reached in one of two ways.

Direct server — simple, but not private about addresses

The host sees every member's real IP, and every member needs the host's IP to connect. Fine on a home network or between people who already trust each other. The app labels these servers DIRECT before you join.

Relayed server — the default

Both sides dial out to the relay and it joins the two calls together. The server only ever sees the relay's address; so do you. A side benefit: the host never has to open a port on their router, because nothing ever connects in to them.

Where this is heading. Today a server lives on one machine, so when that machine is off, the server is off. The plan is mesh hosting: every member's app holds a copy of the server, so a community stays up while anyone is online. The groundwork is built. Every event in a server's history is signed by whoever made it and chained to the one before by a hash, a little like a blockchain without the mining, so any copy can prove it hasn't been tampered with, even one whose encrypted channels it can't open. Copying that history between members is the part not built yet.

📮 How a relay works, step by step

Here is everything that happens between clicking an invite link and seeing the channel list.

From invite link to connected
  1. 1 The server checks in. When the host starts their server, it calls the relay and says "I'm server 7f3a…, send my visitors here." That number is a random 32-byte ID made when the server was created. The server keeps that call open for as long as it runs.
  2. 2 You get an invite. A Farder invite carries three things: which relay to call, the server's ID, and the relay's fingerprint — a short code that only the genuine relay can prove it owns. (For the default relay the app already knows the last two, so those links are shorter.)
  3. 3 Your app calls the relay and checks its ID. The connection is encrypted from the first packet. Before sending a byte of yours, the app checks that the relay's fingerprint matches the one in the invite. If it doesn't — someone impersonating the relay, or sitting in the middle — the app hangs up.
  4. 4 "Put me through to server 7f3a." The relay looks the ID up, gives your connection a ticket number, and starts passing your traffic down the server's open line, stamped with that number so the server can tell members apart. If the server isn't checked in, you get "destination not connected".
  5. 5 You prove who you are — to the server, not the relay. The server sends a random challenge; your app signs it with your private key; the server checks the signature against your public key. No password crosses the wire and there is nothing for anyone to steal and replay.
  6. 6 Voice takes the fast lane. Voice and screen sharing travel as small stand-alone packets rather than one continuous stream, so a lost packet is simply skipped instead of stalling the call. The relay forwards them by ticket number without being able to open them: each call's audio and video are sealed with keys only the people in the call hold.

What the relay can and cannot see

From where the relay sits
Your IP address, and the host's can see
Which server ID you connected to, when, and how much traffic passed can see
Messages in normal channels — it is a middle stop, and today the server→relay→you hop is not sealed end to end for these can see
Messages and files in encrypted channels cannot read
Direct messages cannot read
Voice, video and screen-share audio cannot read
Your private key, your PIN, your history never has them

In short: a relay moves who can see your address from "every server you join" to "the relay operator". That is only an improvement if you trust the relay operator more than the server — which is why anyone can run their own. It is one hop, not Tor: it hides your address from the server, not from the relay.

The relay also fetches things for you. When someone posts a YouTube or X link, the preview card is fetched by the relay, not by your app, so those sites see the relay's address instead of yours. Invite previews work the same way.

⚡ What happens when something goes down

Because the relay stores nothing, losing it loses nothing. It only interrupts the conversation until the line comes back. (Prefer pictures? The step-through chart near the top shows each of these.)

The relay goes offline for a while. Your app shows "Connection lost. Reconnecting…" and tries again every few seconds. Any voice call is ended cleanly so your mic doesn't stay live into nothing. Meanwhile the server is still running on the host's machine with every message intact, and it keeps calling the relay too, backing off from half a second up to thirty seconds between tries. The moment the relay is back, both sides reconnect on their own and you carry on. Nobody has to do anything.
The relay is gone for good. The communities behind it are fine — their data was never on the relay — but they need a new meeting point. A relay's identity is a small file, and if it was backed up, a replacement relay on a new machine can wear the same fingerprint, so apps trust it straight away and only the address changes. Today that move is a manual step for the operator: there is no automatic switch-over to a backup relay yet.
The host's computer goes off. Then the server is off, relay or no relay, until it comes back. This is the real single point of failure today, and the reason mesh hosting is the long-term plan (see above).
Someone sets up a fake relay. It can't pass the fingerprint check in step 3, so the app refuses to talk to it. Pretending to be a relay requires the relay's private key, which never leaves the relay's machine.
A direct server. Relays don't come into it at all. Only the host's machine and their internet connection matter.

🔐 The encryption, layer by layer

There isn't one "Farder encryption". There are several, each doing a different job, stacked like envelopes inside envelopes.

The wire QUIC + TLS 1.3

Every connection — app to relay, relay to server, app to a direct server — is encrypted in transit. Someone on your Wi-Fi or at your internet provider sees scrambled packets going to an address, and that's all. This is the outer envelope: it protects each hop, and each hop opens it.

Is this really the relay? SHA-256 fingerprint pinning

The app doesn't trust a relay because a company vouched for it. It trusts it because the relay proved it holds the key matching the exact fingerprint the app expected. Nobody can issue a "valid" impostor.

Is this really you? Ed25519 signatures

Your identity is a keypair. You log in by signing a one-time challenge, so the server learns your public key and nothing it could log in as you with. The private half is stored encrypted on your machine behind your PIN, and a 24-word phrase can restore it.

Direct messages X25519 + AES-256-GCM

The two of you agree on a shared secret that never travels over the network, and every DM is sealed with it on your machine. Server and relay carry ciphertext they have no key for.

Encrypted channels MLS (OpenMLS)

Group encryption built for chats whose members come and go: keys are refreshed as people join and leave, so a removed member can't read what comes after, and a new one can't read what came before.

Voice, video, screen sharing ChaCha20-Poly1305, per-call keys

Each call gets fresh keys, handed only to the people in it. Every packet is sealed on the sender's machine, and the server and relay route packets they can't open.

Private is not the same as encrypted

Two different settings, two different protections
Private channel Encrypted channel
Other members can read it Only with permission Only if they're in it
Can whoever runs the server read it? yes no
Slash commands, polls, link previews, search All work Switched off

A private channel is a door with a lock in the app: permissions decide who can see it, but it is stored as readable text on the server, like any normal channel. An encrypted channel is sealed on the members' own machines, so the server holds only ciphertext. If the host shouldn't read it, it needs to be encrypted, not just private. The difference matters even more for mesh hosting, where many members would be holding copies.

"Why SSH?" — it isn't SSH, but it's a fair guess

QUIC, not SSH — and what we borrowed from SSH anyway

Farder doesn't use SSH to carry chat. People often think it does, because it borrows SSH's two best ideas:

  • The same kind of key. Your Farder identity is an Ed25519 keypair — the same type modern SSH keys are.
  • Trust by fingerprint. The first time SSH meets a server it remembers that server's fingerprint and warns you loudly if it ever changes. Farder checks relays the same way: against a known fingerprint, with no certificate authority in the middle.

What it doesn't borrow is SSH's transport, because SSH was built to log into a remote computer and type commands, and a chat app needs things SSH doesn't do well:

  • Voice needs to be allowed to lose packets. SSH runs over one strictly ordered stream: if a single packet goes missing, everything behind it waits until it is re-sent. For audio that is a stutter every time the network hiccups. A voice packet that arrives late is useless anyway, so it is better skipped. QUIC can send packets that are allowed to drop.
  • Many things at once. Messages, a big file upload and a voice call all share one connection. On one ordered stream, the upload would hold up your messages. QUIC carries many independent streams over one encrypted connection, so they don't queue behind each other.
  • No certificate authority needed. A relay can run on a bare IP address with a key it made itself, because the app checks the fingerprint directly. Nobody has to buy a certificate or ask anyone's permission to run one.

QUIC is also not exotic: it is the protocol underneath HTTP/3, and a large share of web traffic already uses it.

❓ Quick answers

The questions people ask after reading the above.

Can the relay read my messages?

Your DMs, encrypted channels and voice: no. Normal channels: today, yes — the relay is a stop in the middle of that conversation, the same way the server is. An inner tunnel that closes this is designed and not yet built. If that matters for a conversation, use an encrypted channel.

Who runs the relay?

The app comes with a default relay run by the Farder project. You don't have to use it: when creating a server you can point it at a relay you run yourself (one setup script on any small Linux VPS), or skip relays and go direct.

Can the server owner see my IP?

On a relayed server, no — they see the relay's address. On a direct server, yes. The app tells you which kind it is before you join.

Do my messages live on the relay?

No. The relay keeps a list of which servers are currently checked in and which connections are live, in memory. History, files and members live on the server. Restart a relay and nothing is lost.

If the relay is hacked, what does the attacker get?

What the relay can see (the table above): addresses, who connects to which server, and normal-channel traffic passing through while they're in. Not your encrypted channels, DMs or calls, not your key, and not anything from before they got in — the relay keeps no history to steal.

Is this anonymous, like Tor?

No. A relay is one hop and it knows your address. It protects you from the servers you join and the people in them, not from the relay operator or anyone watching the whole internet at once.

Everything on this page can be checked against the source on GitHub. Back to the main page.