No One Is Coming to Help: Owning Your Matrix Stack

📱 Kim Jong Rails 📅 November 23, 2025
matrixself-hostingoperationsdecentralizatione2ee

The Illusion of “Easy Self-Hosting”

You installed Docker. You ran docker-compose up. Your Matrix homeserver started.

Congratulations. You are now responsible for:

There is no helpdesk. No SLA. No one is coming to help.

This is what sovereignty costs.

What You Actually Installed

When you spun up that Matrix homeserver, you didn’t install “IRC with persistence.”

You installed a replicated state machine with cryptographic authentication and eventual consistency guarantees.

Let me show you what that means.

IRC: The Baseline

IRC architecture:
Client → TCP socket → IRCd → Relay to other servers
Messages: ephemeral lines of text
State: current channel membership
History: none (unless you run a bouncer)
Encryption: maybe SSL to server
Auth: SASL if you're fancy
Failure mode: disconnect, rejoin, you missed everything

Simple. Stateless. Fragile.

When the IRC server dies, your messages die. When you disconnect, you lose history. When netsplits happen, channels fracture and you pick sides.

This simplicity is why IRC is still running 35 years later. No state to corrupt. No keys to lose. Just text pipes.

Matrix: The State Machine

Matrix architecture:
Client → Homeserver → Room DAG → Federation → Other homeservers
Messages: signed events with prev_events and auth_events
State: replicated across all participating servers
History: permanent (until you redact or purge)
Encryption: E2EE via Olm/Megolm, per-device keys
Auth: event signatures, power levels, state resolution rules
Failure mode: complex (see next 2000 words)

Complex. Stateful. Resilient.

When your homeserver dies, other servers still have the room state. When you disconnect, history is waiting when you return. When federation splits, state resolution algorithms decide who wins.

This complexity is why Matrix can provide E2EE, decentralization, and auditability. But it’s also why you need to understand what you’re running.

The Event Graph Is Not a Chat Log

This is where most people’s mental model breaks.

IRC stores nothing. Messages flow through the server like water through a pipe.

Matrix stores everything. Every message is an event in a directed acyclic graph (DAG).

Event Anatomy

{
  "type": "m.room.message",
  "sender": "@kim:dag.ma",
  "content": {"body": "No one is coming to help"},
  "event_id": "$abc123",
  "room_id": "!roomabc:dag.ma",
  "origin_server_ts": 1700000000000,
  "prev_events": ["$xyz789"],
  "auth_events": ["$create", "$power", "$join"],
  "depth": 42,
  "signatures": {...}
}

Key points:

This is not a line in a log file. This is a node in a distributed state machine.

When your homeserver receives this event:

  1. Validates signatures against server keys
  2. Checks auth chain (does sender have permission?)
  3. Resolves conflicts if multiple events at same depth
  4. Stores in DAG
  5. Forwards to other federated servers

If any step fails, the event is rejected.

If You Bought Crypto in the Past Year, You’ll Understand This

Every emoji reaction you send? That’s a transaction.

Every message? Transaction.

Every room join? Transaction.

All federated servers record these transactions.

You send "👍" in a federated room:
dag.ma records: event $abc123, type: m.reaction, sender: @you:dag.ma
matrix.org records: event $abc123, type: m.reaction, sender: @you:dag.ma
tchncs.de records: event $abc123, type: m.reaction, sender: @you:dag.ma

Public ledger? No.
Distributed state machine? Yes.

If you’re NOT federated (private homeserver, no external rooms):

Unlike cryptobros who create a new whitepaper to rug-pull you:

Matrix has one spec. No forks. No “Matrix Classic” vs “Matrix Cash.” No DAO governance vote to change the protocol.

All servers speak the same language:

This is discipline.

Civilized servers talking to each other with agreed-upon rules.

No one is forking Matrix to pump a token. No one is proposing “Matrix 2.0 governance NFTs.”

The protocol is boring. The operations are hard. The sovereignty is real.

Crypto promised decentralization and gave you speculation.

Matrix promises federation and gives you operational responsibility.

One is a grift. One is infrastructure.

State Resolution: When Servers Disagree

Here’s a fun scenario.

Timeline:

  1. User on dag.ma sends message A
  2. User on matrix.org sends message B at same time
  3. Both servers think their message came first
  4. Both servers forward to each other
  5. Now what?

IRC’s Answer

*SPLIT*
#channel splits into two
You pick which server to trust
Maybe an oper manually reconciles later
Maybe you just accept the chaos

Matrix’s Answer

State resolution algorithm v2 (room version 2+):
1. Build auth chains for both events
2. Check power levels from auth events
3. Apply lexicographic ordering on event IDs
4. Compute resolved state
5. Both servers converge to same result

This is deterministic. Given the same events, all servers reach the same conclusion about room state.

This is also why room state can break.

If your homeserver:

State resolution will produce garbage. And you can’t just “restart the room” like you restart an IRC channel.

You debug the event DAG, repair auth chains, or upgrade the room version.

E2EE: The Key Hierarchy You Didn’t Ask For

You wanted encrypted messages. Matrix gave you a cryptographic trust graph spanning devices, cross-signing keys, and key backup.

Let me explain why this complexity exists.

The Threat Model

What Matrix protects against:

What Matrix doesn’t protect against:

You are the weakest link.

Device Keys (Ed25519 + Curve25519)

When you log in to Matrix on a new device:

Device generates:
- Ed25519 signing key (identity)
- Curve25519 identity key (Olm sessions)
- Multiple Curve25519 one-time keys (prekeys)

These keys are uploaded to homeserver
Other devices discover them via /keys/query

Every device has unique keys. Your phone, laptop, and tablet are separate cryptographic identities.

Why?

Because if one device is compromised, the attacker doesn’t get access to other devices’ messages.

Also why you have to verify every device.

Olm: 1-to-1 Sessions

For direct messages and key exchange:

Olm (Double Ratchet):
1. Alice fetches Bob's identity key and one-time key
2. Alice derives shared secret (ECDH)
3. Alice sends encrypted message
4. Bob ratchets forward, derives new keys
5. Forward secrecy achieved (old keys deleted)

Olm provides perfect forward secrecy. If your device is compromised today, yesterday’s messages are safe (keys were deleted).

Olm does not scale to rooms. Encrypting for 1000 devices = 1000 separate Olm sessions.

Megolm: Room Sessions

For encrypted rooms:

Megolm (group chat):
1. Sender generates session key
2. Sender encrypts session key to each device (via Olm)
3. Sender uses session key to encrypt messages
4. Recipients decrypt session key, then decrypt messages
5. Session rotated periodically

Megolm trades perfect forward secrecy for efficiency.

Session keys are reused until rotation. If an attacker gets the session key, they decrypt all messages in that session.

But they can’t decrypt future sessions (because new session key generated).

And they can’t decrypt past sessions (if you enabled key rotation and old keys were deleted).

Cross-Signing: The Trust Root

You have 5 devices. How do other users know all 5 devices belong to you?

Cross-signing.

Master key (offline, high-security):
  ├─ Self-signing key (signs your devices)
  ├─ User-signing key (signs other users you trust)

When you verify a device:
1. Device signs event with device key
2. Self-signing key signs device
3. Master key signature proves self-signing key is yours
4. Other users trust your master key → trust all your devices

This is a web of trust.

If you verify Alice’s master key, you trust all devices Alice’s self-signing key vouches for.

If you lose your cross-signing keys, your trust graph collapses.

Other users will see “unverified” on all your devices. You’ll see “unverified” on everyone else.

You have to re-verify everything.

Key Backup: Recovery vs Security

You encrypted your messages. Now you bought a new phone.

Can you read old messages?

Only if you backed up your Megolm session keys.

Key backup flow:
1. Client generates recovery key (or uses passphrase)
2. Client encrypts Megolm session keys
3. Client uploads encrypted keys to homeserver
4. New device downloads encrypted keys
5. New device decrypts with recovery key

Trade-offs:

With key backup:

Without key backup:

You choose.

Most users choose key backup because losing message history is unacceptable.

Security purists disable it and accept the loss.

There is no “secure and convenient” option. Pick one.

Federation Pain: Other People’s Servers Are Your Problem

You run dag.ma. I run it well. Uptime is high, certs are valid, DNS is correct.

But you’re in rooms with users from matrix.org, tchncs.de, and randomserver.xyz.

If any of those servers are misconfigured, your users experience breakage.

Common Federation Failures

Expired TLS certificates:

randomserver.xyz cert expired
Your homeserver refuses to federate
Users on randomserver.xyz appear "offline"
Messages don't sync

Your options:

  1. Wait for randomserver.xyz admin to fix cert
  2. Tell your users to complain to randomserver.xyz
  3. Do nothing (you can’t fix other people’s servers)

DNSSEC validation failures:

tchncs.de has broken DNSSEC
Your homeserver can't resolve tchncs.de
Federation fails

Your options:

  1. Disable DNSSEC validation (security risk)
  2. Wait for tchncs.de to fix DNS
  3. Do nothing

State resolution conflicts:

matrix.org and dag.ma disagree on room power levels
State resolution algorithm runs
One version wins, one loses
Some users' messages rejected

Your options:

  1. Examine event DAG to find conflicting auth events
  2. Manually construct resolution event
  3. Upgrade room version to reset state
  4. Rage quit and start new room

Notice a pattern? You don’t control other servers. But their failures impact your users.

Operational Footguns You Will Step On

Let me save you some pain.

Footgun 1: Unverified Devices

Scenario: User complains “I’m seeing a red warning on my messages.”

Cause: They logged in on a new device and didn’t verify it.

Why this happens: Matrix shows “unverified device” warnings to prevent MITM attacks. If an attacker adds a rogue device, you’d see the warning.

Fix: Verify the device (SAS emoji or QR code).

User reaction: “Why is this so complicated? Discord doesn’t make me do this.”

Your response: “Discord reads your messages. Matrix doesn’t. Pick one.”

Footgun 2: Lost Cross-Signing Keys

Scenario: User wiped device without backing up cross-signing keys.

Cause: They didn’t export security key or set up key backup.

Result:

Fix: Reset cross-signing, re-verify all devices and all users.

User reaction: “I just wanted to reinstall my OS!”

Your response: “You control your keys. That means you’re responsible for not losing them.”

Footgun 3: Corrupted Room State

Scenario: Messages in a room suddenly stop syncing.

Cause: Database migration corrupted event DAG, or state resolution hit a pathological case.

Symptoms:

ERROR: event rejected: auth chain failure
ERROR: missing prev_events
ERROR: state resolution failed

Fix:

  1. Check homeserver logs for rejected events
  2. Identify missing auth_events or prev_events
  3. Fetch missing events from federated servers
  4. Rebuild state from auth chain
  5. If unfixable: upgrade room version (migrates to new DAG)

User reaction: “Why can’t you just restart it?”

Your response: “Because this is a distributed state machine, not a Docker container.”

Footgun 4: Running Out of Disk Space

Scenario: Homeserver stops responding. Disk is full.

Cause:

Fix:

  1. Emergency: delete old media, purge room history
  2. Permanent: configure media retention, log rotation, event purging

User reaction: “I thought PostgreSQL handled this!”

Your response: “PostgreSQL stores data. You decide what data to keep.”

The Operational Runbook You Need

If you’re serious about running Matrix, here’s what you monitor and maintain.

Dagma’s 3-Server Architecture

Dagma isn’t a monolith. It’s three separate services:

Tribune (Public-facing, always online)

Embassy (Federation, can be isolated)

Politburo (Admin, 99% offline)

This isn’t redundancy — it’s attack surface reduction.

Traditional homeservers expose admin, federation, and users on the same endpoint. If you can reach the server, you can probe for admin exploits.

Dagma exposes only what needs to be exposed. Politburo isn’t online unless you need it.

Note: The operational commands below assume Dagma is fully implemented. Until then, these are planned operations, not current API.

Daily Checks

Federation health:

curl https://federationtester.matrix.org/api/report?server_name=dag.ma

Check for:

Disk usage:

df -h /var/lib/postgresql
du -sh /var/lib/dagma/media_store

Event processing lag:

SELECT COUNT(*) FROM event_forward_extremities WHERE room_id = '!yourroom:dag.ma';

If count is high, state resolution is struggling.

Weekly Maintenance

Purge old media:

# Access Politburo (admin interface)
dagma politburo purge-media --before="30 days ago"

Vacuum database:

VACUUM ANALYZE;

Review error logs:

journalctl -u dagma | grep ERROR | tail -100

Check room versions:

SELECT room_version, COUNT(*) FROM rooms GROUP BY room_version;

Upgrade rooms on old versions (v1-v5 are deprecated).

Monthly Review

TLS certificate renewal:

certbot renew --dry-run

Backup verification:

Security audit:

Disaster Recovery

Lost database:

  1. Restore from PostgreSQL backup
  2. Verify event DAG integrity
  3. Re-join federated rooms (if state lost)

Lost media:

  1. Restore from media_store backup
  2. If none: media is gone (federated servers may still have copies)

Lost signing keys:

  1. Generate new signing keys
  2. Federated servers will re-fetch via /.well-known/matrix/server
  3. Old events remain signed with old keys (still valid)

Compromised server:

  1. Rotate signing keys immediately
  2. Invalidate all access tokens
  3. Audit event log for malicious events
  4. Notify federated servers if needed

The Culture Shift: Treat Your Homeserver Like Infrastructure

You don’t restart your database “just to see if it fixes things.”

You don’t deploy to production without testing.

You don’t skip backups because “it’s just a chat server.”

Apply the same discipline to Matrix.

Testing Changes

Before changing configs:

  1. Understand what the setting does
  2. Test on staging
  3. Deploy to production with rollback plan

Monitoring

Metrics you should track:

Use Prometheus + Grafana:

# dagma config
enable_metrics: true
metrics_port: 9000

Set alerts for:

Documentation

Document your setup:

Why?

Because when things break at 3am, you won’t remember why you changed that config six months ago.

Comparison: Centralized vs Self-Hosted

AspectDiscord/SlackSelf-Hosted Matrix
Who owns the dataDiscord Inc.You
Who reads messagesDiscord (no E2EE)No one (E2EE)
Uptime responsibilityDiscord SREYou
Support availability24/7 helpdeskNone
Cost of downtimeReputational (Discord)Reputational (you)
Key custodyDiscord holds keysYou hold keys
Lost passwordReset via emailLost keys = lost messages
Server compromiseAll messages exposedE2EE messages safe
Federation failureN/A (centralized)You debug or wait
Room state corruptionDiscord fixes itYou fix it
Operational complexityZero (SaaS)High (DIY)

Trade-offs:

Discord is easier. You pay with surveillance, vendor lock-in, and zero control.

Matrix is harder. You pay with operational burden, complexity, and responsibility.

Choose the trade-off that matches your threat model.

What You Should Actually Do

If you’re running Matrix in production (not just tinkering):

Minimum Viable Operations

Infrastructure:

Monitoring:

Documentation:

Skills:

When to Stay Centralized

Use Discord/Slack if:

This is a valid choice. Not everyone needs decentralization.

When to Use Managed Matrix

Use Element Matrix Services / Beeper if:

Also valid. Outsource the ops, keep the protocol benefits.

When to Self-Host

Self-host Matrix if:

This is the hard path. But it’s the only path to true autonomy.

Timeline Perspective

From Ring -5, I observe:

Timeline Ω-12 (current):

Timeline Ω-7 (ideal):

The gap between Ω-12 and Ω-7 is education and discipline.

Conclusion

No one is coming to help.

When your homeserver goes down, there’s no SRE team on-call.

When state resolution breaks, there’s no support ticket.

When you lose your cross-signing keys, there’s no password reset.

This is the cost of decentralization.

You own the infrastructure. You own the keys. You own the responsibility.

Discord doesn’t ask you to verify devices because Discord reads your messages.

Matrix asks you to verify devices because Matrix doesn’t.

Slack doesn’t ask you to back up keys because Slack holds them.

Matrix asks you to back up keys because you hold them.

Teams doesn’t ask you to debug state resolution because there’s only one server.

Matrix asks you to debug state resolution because there are 10,000 servers.

Complexity is the price of autonomy.

Operational burden is the price of sovereignty.

Key management is the price of encryption.

If you’re not willing to pay these prices, stay centralized.

But if you are willing, if you accept the responsibility, if you treat your Matrix stack like production infrastructure and not a toy —

Then you get something Discord can never offer:

Complete control. Complete privacy. Complete independence.

No surveillance. No vendor lock-in. No one reading your messages.

And yes: No one coming to help.

Because you don’t need help.

You are root.

Changelog: 2025-11-23 - Operational reality of self-hosted Matrix and the cost of sovereignty

Note: You are in Timeline Ω-12. Running Matrix doesn’t make you Ω-7. Operating it well does.

← Back to Proclamations đŸ›ïž Homepage

Dagma Matrix Homeserver | Built by the Derails Development Bureau

"All your DAG are belong to us" - Kim Jong Rails, 2025

FAQ | Terms | Proclamations | Homepage