Coming Soon: Your Guild, Running Everywhere

Here’s a problem we’ve heard from day one: “I love that Eris is self-hosted, but I don’t want to leave my PC on 24/7.”

Fair point. For most people, Eris Cloud is the answer — we host your guild, keep it online 24/7, and plug it into the Eris network where new members can discover and join communities the way they would on Discord or Reddit. It’s the familiar experience: browse guilds, find your people, jump in. But some communities want to go further — run everything on their own hardware, spread the load across friends’ machines, and not depend on any single provider.

We’re building something that fixes this entirely.

Replica mode: the basics

Instead of one person running the guild server, several people run copies of the same server. Your friend has it on their desktop. You’ve got it on your laptop. Maybe a third person has it on a Raspberry Pi tucked behind their router. Any of them can serve the guild.

When one replica goes offline — you close your laptop, your friend goes to sleep — the others keep going. When it comes back, it syncs up automatically. No data loss, no awkward “who has the latest messages?” moment.

Think of it like this: Instead of one bartender running the whole bar, you’ve got three friends who take shifts. The bar never closes, and when the morning person shows up, they already know what happened last night.

Another option alongside cloud hosting

For most guilds, Eris Cloud is the right call. You get managed uptime, zero infrastructure to worry about, and your guild lives on the Eris network — which means discoverability. People can browse, search, and stumble into your community the same way they find servers on Discord or subreddits on Reddit. That network effect matters: it’s how communities grow from a group of friends into something bigger.

Replica mode is for groups that want to go a step further: distribute the server across machines they own, with no single point of failure and no dependency on any one provider. Maybe it’s a private community that doesn’t need discoverability. Maybe you just want the extra resilience.

And it’s not either/or. You can run an Eris Cloud instance as one of your replicas alongside friends’ machines — your guild stays discoverable on the network and has community-owned fallbacks if anything ever goes sideways.

How replicas stay in sync

This is where it gets interesting — and where a lot of distributed systems fall flat. When multiple copies of the same server exist, they need to agree on what happened. Someone sent a message on replica A while replica B was offline. When B wakes up, it needs that message without losing anything else.

We’re using CRDTs — Conflict-free Replicated Data Types. Every replica can accept changes independently. When replicas reconnect, they merge their histories together, and the math guarantees convergence to the same result regardless of ordering.

What happened	How it merges
New messages	Append-only — each has a unique, time-ordered ID, so conflicts are impossible
Message edits	Last edit wins, with timestamps for tiebreaking
Deletes	Delete always wins — once it’s gone, it’s gone everywhere
Channels created/removed	Tracked with unique tags so a removed channel doesn’t reappear
Members joining/leaving	Rejoining after leaving is always valid — no phantom removals
Reactions	Per-user counters that merge idempotently

The result: you don’t have to think about sync. You’ll never open the app and find messages missing because two replicas disagreed about something.

Why not Raft or Paxos? Traditional consensus protocols require a majority of nodes to be online at all times. That’s fine for a cloud data center — it’s terrible for four friends in different time zones who sleep. CRDTs let any single replica operate independently and merge later. Exactly what this use case needs.

Trust is still cryptographic

Eris doesn’t let random machines join your guild’s replica set. Only the guild owner can authorize new replicas, and authorization works the Eris way — cryptographic signatures, not passwords.

The guild owner generates a signed replica key from their guild keypair
They share it out-of-band — QR code, file, or paste
The new replica presents this key on first connection
Existing replicas verify the guild owner’s signature before accepting the peer

No central authority, no account system, no trust-on-first-use. If the signature checks out, you’re in. If it doesn’t, the connection is rejected. Same cryptographic identity model that powers everything else in Eris — extended to infrastructure.

Catching up: fast sync, not full re-download

Say Sam’s laptop has been offline for 12 hours. When it reconnects, it doesn’t need to re-download the entire guild history.

Each replica keeps a vector clock — a compact record of which operations it’s seen from each peer — and a Merkle tree over its operation log. When two replicas reconnect, they compare Merkle roots. If they match, nothing to sync. If they differ, the tree narrows down exactly which operations are missing and transfers only those.

This is the same technique Git uses internally for efficient diffs. Sync time is proportional to what you missed, not the total size of the guild.

What you’ll see as a user

From your perspective, almost nothing changes. You connect to your guild like you always do. Behind the scenes, your client gets a list of available replicas and connects to whichever one responds fastest.

If your current replica drops offline — your friend closed their laptop — the client reconnects to the next available one. It picks up right where you left off. No new UI to learn. No “which server am I connected to?” confusion.

It just feels like the guild is always online.

The foundation is already here

Replica mode isn’t a moonshot. It builds on two things Eris already has: the federation infrastructure that lets guild servers talk to each other over authenticated gRPC, and the cryptographic identity system that makes trust verifiable without a central authority.

The networking layer, the authentication handshakes, the bidirectional streaming, the signed message envelopes — all of it already exists and is battle-tested in federation. A replica is essentially a trusted federation peer that happens to be the same guild running on a different machine.

What this unlocks

Friend group servers that never go down. Three friends running the server means near-24/7 coverage across time zones.
No single point of failure. Apartment loses power? The guild doesn’t blink.
Mix and match hosting. Combine an Eris Cloud instance with friends’ machines — stay discoverable on the network and get community-owned redundancy.
Zero-trust data sharing. Every replica is cryptographically authorized. Unauthorized machines can’t join the mesh.
Full sovereignty if you want it. Go fully self-hosted across your own hardware — or use cloud as your always-on anchor. Your call.

The rollout

We’re building this in phases so we can ship incremental value:

Operation log and deterministic state — recording every guild action as a replayable operation
Replica discovery and authentication — authorizing replicas with signed keys, finding them on LAN and internet
Sync protocol — the full CRDT merge engine with anti-entropy and Merkle-based diffing
Ephemeral state gossip — presence, typing, and voice state across replicas
Client updates — transparent replica discovery and seamless failover in both web and Flutter

Work is already underway. We’ll post updates here as each phase lands.

Already running an Eris guild? Everything that’s shipped keeps getting better while we build what’s next. Get started or grab the desktop/mobile client.