Shield

A fully open-source, end-to-end-encrypted alternative to Discord — servers, channels, direct messages and voice — built on the Matrix protocol.

Shield is not a from-scratch chat protocol. It is an infrastructure and product blueprint that composes established, audited open-source projects into a Discord-like experience while keeping the security guarantees Discord does not offer: end-to-end encryption for messages and calls, no central point of truth, and self-hostable federation across independent servers in different physical locations.

Why Matrix

We build on Matrix because it already solves the hardest problems — group end-to-end encryption, federation, device verification, encrypted key backup — with production-grade, audited implementations. Building those ourselves would be irresponsible for a security-focused product. Our work is UX, branding, deployment and operations, not cryptography.

Discord concept	Shield / Matrix equivalent
Account	Matrix user @alice:node-eu.shield.example
Server / guild	Matrix Space (a room that groups other rooms)
Text channel	Matrix room
Voice channel	MatrixRTC call (Element Call) over a LiveKit SFU
Direct message	Encrypted 1:1 Matrix room
Physical server	A homeserver (conduwuit) — one self-contained binary per location

Architecture at a glance

• Homeserver: conduwuit (Rust) — a single self-contained binary with an embedded database. No external Postgres, no Redis, no shared storage. Ideal for geographically separate machines that do not share a LAN. See the note on the conduwuit fork situation.
• Replication model: Matrix federation — eventual consistency with deterministic state resolution (a DAG of events), not quorum/voting. Each node is always available, even when partitioned from the others, and reconciles automatically when reconnected. This is the correct model for WAN-separated servers. See docs/00-architecture.md.
• Voice/video: Element Call (MatrixRTC) on a LiveKit SFU, with per-participant client-side E2EE.
• Encryption: Matrix E2EE (Olm/Megolm today, MLS on the roadmap), cross-signing device verification, and encrypted server-side key backup.
• Reverse proxy / TLS: Caddy (automatic HTTPS + .well-known delegation).

Repository layout

.
├── README.md                     ← you are here
├── docs/
│   ├── 00-architecture.md        ← decisions, CAP trade-off, federation model
│   ├── 01-homeserver-conduwuit.md← deploy a single homeserver
│   ├── 02-federation.md          ← delegation, TLS, bootstrapping a 2nd location
│   ├── 03-voice-livekit.md       ← Element Call + LiveKit + voice E2EE
│   ├── 04-security-e2ee.md       ← E2EE model, key backup, threat model
│   ├── 05-clients.md             ← client strategy (Element fork / rust-sdk)
│   ├── 06-operations.md          ← backups, monitoring, upgrades, runbook
│   └── 07-roadmap.md             ← phased delivery plan
├── deploy/
│   ├── conduwuit/                ← homeserver compose + config + Caddy
│   ├── livekit/                  ← SFU + JWT auth service
│   ├── element-call/             ← voice web app
│   └── well-known/               ← Matrix delegation files
└── scripts/
    ├── bootstrap-server.sh       ← stand up a new location
    └── check-federation.sh       ← verify federation + delegation

Quick start

1. Read docs/00-architecture.md to understand the model and the one real caveat (account portability).
2. Stand up the first homeserver: docs/01-homeserver-conduwuit.md.
3. Wire up federation and add a second location: docs/02-federation.md.
4. Add voice: docs/03-voice-livekit.md.

Status

Blueprint / infrastructure-as-documentation. See docs/07-roadmap.md for the phased plan.

License

AGPL-3.0-only — matching the Matrix ecosystem it builds on. See LICENSE.