A Week in Matrix: Moderation, Spaces, and Federation Woes
Running a Matrix community is not for the faint of heart. One admin's week-long debugging log, published on piegames.de, reveals the gritty reality behind the buzzwords. It's a story of accidental notifications, policy room forensics, split-brain rooms, and a moderation bot that silently died for a month. Here's what happened, and what it means for anyone self-hosting Matrix.
Monday: The Space Room Chat Incident
A user accidentally posts in a Matrix space's room, notifying every member. Spaces are just regular rooms, and old clients render them as such. New clients, however, show confusing UI when people chat in them. The admin notes that most clients don't adjust space room permissions to prevent chatting. They had to use Element Web's devtools to inspect the room, grant themselves admin, and change permissions to disallow chatting.
Takeaway: If you run a space, proactively set permissions on the space room to m.room.power_levels to prevent non-mods from sending messages. Check your client's devtools for advanced room controls.
Tuesday: The Spurious Ban Mystery
A user reports being banned from the space for no reason. The admin queries Draupnir (a moderation bot) for the user handle — nothing. Then they query by domain and find a ban rule: m.policy.rule.server with m.ban for the user's domain, originating from a policy room the space subscribes to. The domain had once had open registrations, leading to spam. The admin joins the policy room to investigate, but searching for the domain in Element fails because Element only searches m.messages events. They export the room as HTML and grep it, finding seven hits. The whole investigation took 40 minutes when it should have taken two. Two weeks later, the user is still banned, and the admin can't easily override the ban list.
Takeaway: Policy rooms (like m.policy.rule.server) can ban entire domains. If you subscribe to a community policy list, be aware that you're inheriting domain bans. To override, you might need to fork the list or use a local policy list with higher priority.
Wednesday: The Invisible Room Bug
A new member can't see a room that's suggested in a space. Manually joining works, but the room doesn't appear in the space's room list. Reproduced across accounts and homeservers. Removing and re-adding the room doesn't help, nor does tombstoning. The workaround: when a space admin joins the room, it appears; when they leave, it disappears again.
Takeaway: This is likely a federation sync issue. If you encounter it, have an admin join the room temporarily to force a sync.
Thursday: Draupnir Dies for a Month
After routine maintenance, Draupnir stops responding to admin commands, though logs show it's processing them. After a month of debugging, the culprit is found: Dendrite's default config drops all egress IPv6 traffic. The admin notes that Dendrite is deprecated, and migrating between homeservers is painful. They're stuck on "slowly rotting foundations."
Takeaway: If you run Dendrite, check your config for IPv6 settings. More broadly, consider the long-term maintenance burden when choosing a homeserver implementation.
Friday: Permissions Reset and Split-Brain
The same space room issue recurs: permissions have reset. The admin re-applies them, but they don't propagate to other homeservers — a split-brain. Users on one side can still chat, but messages are soft-failed on the other side, making them invisible. They decide to upgrade the room version rather than investigate further.
Takeaway: Split-brain in Matrix rooms can cause inconsistent permissions. Upgrading the room version is a common fix.
Saturday: Federation Degradation
The admin's homeserver had degraded federation for days due to a DNS issue. After fixing it, the server desynced, thinking a bot account wasn't in a room. They had to kick and re-invite the bot. The admin worries: "How many others users am I accidentally ghosting because my homeserver just 'forgot' about them?"
Takeaway: Federation issues can cause subtle state desyncs. If you notice missing members, try kicking and re-inviting.
Sunday: The PR vs. Reality Gap
The admin criticizes the Matrix Foundation's PR, which boosts happy user stories, contrasting with their own experience. They argue that Matrix works well for small, simple use cases but struggles in larger, complex communities. They point out that spaces are low priority, despite being marketed as a Discord alternative. The admin says, "Maybe I'd be feeling less bitter about all of this if not for all the broken promises over all these years."
Takeaway: Evaluate Matrix's fit for your community size and complexity. If you're running a large community, be prepared for friction.
The Bigger Picture
This week-in-the-life is a sobering counterpoint to Matrix's marketing. It highlights several systemic issues:
- Spaces are underdeveloped: They're just rooms with extra metadata, leading to confusing UX and permission bugs.
- Policy rooms are blunt instruments: Domain bans can be overbroad and hard to override.
- Homeserver diversity is a double-edged sword: Non-flagship servers like Dendrite have bugs that can cripple moderation.
- Federation is fragile: DNS misconfigurations and split-brain scenarios can cause invisible state divergence.
For developers, this is a call to action: contribute to Matrix's core, improve spaces, and document operational best practices. For users, it's a warning to set realistic expectations.
What You Should Do Now
- If you run a Matrix space, check your space room permissions today.
- Review your policy list subscriptions for overbroad bans.
- Test your homeserver's federation health, especially IPv6.
- Consider room version upgrades to avoid split-brain issues.
- If you're evaluating Matrix for a large community, run a pilot with the actual software you'll use.
