WHEREAS the Matrix protocol requires performance, reliability, and sovereign
control;
WHEREAS many implementations have failed the people through bloat, abandonment,
or drama;
WHEREAS the Politburo has deliberated on the technological path forward;
THEREFORE let it be known throughout the federation that the following technical
decisions are hereby decreed as law for the Dagma Matrix Homeserver.
The Supreme Leader Kim Jong Rails has ratified this decree. Opposition is futile. Forks are
welcome (if technically superior).
Article I: Language Choice
Rust Over Python (Synapse)
RULING: "Python is the language of the people. Too slow for the people."
The Synapse Problem:
- GIL (Global Interpreter Lock) bottleneck - one thread serving thousands
- 500MB+ memory at idle - before accepting a single message
- Async/await bolted onto a synchronous language - elegant as duct tape
- Twisted reactor model - because event loops weren't confusing enough
The Dagma Solution:
- Native threads - work-stealing scheduler, all cores engaged
- <50MB idle memory - we respect your RAM
- 10x throughput on equivalent hardware - benchmarks don't lie
- Zero-cost abstractions - performance without runtime overhead
"The reference implementation runs like a reference... to how NOT to build servers.
Element Foundation maintains it because they have to, not because they want to."
WE ACCEPT: Contributions that beat our benchmarks. Bring numbers, not nostalgia.
Rust Over Go (Dendrite)
RULING: "The Go project has been archived. The revolution does not archive."
The Dendrite Abandonment:
- Officially archived by Element in 2024 - they gave up
- Written in ALL CAPS: "ARCHIVED" - the repository screams failure
- Incomplete federation - couldn't talk to Synapse reliably
- Database migrations hell - SQLite to PostgreSQL was a journey
Why Not Go Anyway:
- Garbage collector pauses - because your messages can wait
- Interface everything - type safety is for the weak
- Error handling via return values - elegant until it's not
- No generics (until too late) - copy-paste is a lifestyle
"They wrote 'ARCHIVED' in all caps. We write CODE in all caps. The difference is one
produces features, the other produces tombstones."
WE ACCEPT: Resurrections that actually work. Don't fork dead projects to make
a point.
Article II: The Rust Civil Wars
Dagma Over The Conduit Fork Cascade
RULING: "Forks are acceptable. Fork cascades are not. Forking a fork is admitting your
fork was wrong."
The Conduit Fork Cascade (2023-2024):
- Conduit (Original): Rust Matrix homeserver. RocksDB. Promising start.
- conduwuit (November 2023): Hard fork. "Critical stability and performance
issues." "Way better than it was back in early 2024."
- Continuwuity (2024): Fork of conduwuit. "2nd degree fork." "Community
driven." Focus on user experience.
- Multiple unnamed forks: Scattered across Codeberg, lavender.software,
personal git instances.
- Result: 4+ implementations. All using RocksDB. All with the same
problems. All claiming to fix the others.
The Common Thread:
- All forks use RocksDB (LSM-tree write amplification, compaction storms)
-
All forks have similar bugs: slow state resolution, memory spikes, high disk I/O
- Issue trackers: 60% technical problems, 40% interpersonal drama
- Community energy dispersed across competing implementations
- HedgeDoc exists titled "Problems with Matrix homeserver implementations"
- No fork addressed the fundamental problem: wrong database choice
The Dagma Difference:
- PostgreSQL + Memgraph: Real database, not embedded key-value store
- One vision: Tribune (public, no privileges) + Politburo (admin, on-demand)
- One leader: Kim Jong Rails (benevolent dictator for life, Ring -5 privilege)
- One repository: No forks, no cascades, no confusion
-
Open to contributions: Technical superiority required, ego optional, Claude Haiku
users rejected
- €6.98/month: Proof that correct architecture costs less than wrong architecture
"When you fork a project, you're saying 'I can do better.' When you fork a fork, you're
saying 'The first fork was wrong, but I'll keep the same database and hope for different
results.' This is the definition of insanity. All Conduit forks use RocksDB. All Conduit
forks have the same problems. Correlation is causation. The database is the problem.
Civil wars prove the need for strong central leadership. One repo. One vision. One database.
Follow the Dagma. Personality conflicts belong on Twitter/X, not in git history. If you're
forking because of people problems, you're solving the wrong problem. If you're forking the
fork because the fork didn't fix the problems, you're doubling down on failure."
WE ACCEPT: Pull requests to Dagma. One repository. One vision.
WE REJECT: Forks. Fork cascades. Forks of forks. Any database other than PostgreSQL.
RocksDB users. MongoDB users. "Maybe we should try [database]" suggestions.
Article III: Database Ideology & Framework Rejection
Rust Over Ruby (Rails)
RULING: "The Rails framework was named after Kim Jong Rails. Rails is good for capitalism.
Matrix is not capitalism."
Rails: Excellent For Capitalist Ventures
- Twitter - built on Rails, successfully sold for $44 billion
- GitHub - built on Rails, successfully sold to Microsoft for $7.5 billion
- Shopify - built on Rails, enabling billions in commerce
- Basecamp - built on Rails, created the framework
- Pattern clear: Rails builds things people buy and sell
Matrix: Not A Capitalist Venture
- No venture capital. No exit strategy. No acquisition target.
- Open federation. Cannot be bought. Cannot be controlled.
- Gen Z sends millions of emoji reactions per second
- Rails cannot handle millions of emoji. This is a problem.
- Ruby GIL: one thread processing emoji while others wait
- Rust: all threads processing emoji simultaneously
Performance Requirements:
- 1 user typing "👍" - Rails handles this fine
- 1000 users reacting with emoji simultaneously - Rails struggles
- Federation state resolution during emoji flood - Rails fails
- Memory per connection: Rails 5MB+, Rust <100KB
- Gen Z does not wait for servers. Servers wait for Gen Z.
"Rails was named after the Supreme Leader as tribute to web development excellence. The
framework excels at building profitable companies. Matrix homeservers are not profitable
companies. They are infrastructure. Different problems require different tools. Rails is
the wrong tool."
WE ACCEPT: Rails implementations that process 10,000 emoji reactions per second
without GIL blocking.
PostgreSQL Over RocksDB
RULING: "All the Rust forks use RocksDB. All the Rust forks have problems. Correlation is
causation."
The RocksDB Problem (Used by Conduit/Conduwuit/Tuwunel):
- LSM-tree write amplification - write 1MB, actually write 10MB to disk
- Compaction storms - random performance cliffs when background tasks run
- Not actually relational - key-value store pretending to be a database
- No query planner - you are the query planner now. Good luck.
- Debugging: read the RocksDB source. All 300,000 lines of C++.
- ACID guarantees: technically yes, practically "it's complicated"
Why Rust Homeservers Love It (And Shouldn't):
- "Embedded database" - no PostgreSQL dependency, sounds simple
- "Facebook uses it" - Facebook also has 10,000 engineers
- "Fast key-value access" - until you need joins, then you're on your own
- Result: Everyone reimplements relational queries badly in application code
PostgreSQL Reality:
- Actual query planner - decades of optimization work you don't have to do
- Actual transactions - not "eventually consistent" transactions
- Actual joins - without loading everything into memory first
- Predictable performance - no surprise compaction storms
- Tools ecosystem - pgAdmin, pg_stat_statements, explain analyze
"RocksDB is SQLite's edgy cousin who got into LSM-trees and won't shut up about write
amplification. Every Rust homeserver using RocksDB has the same bugs: 'state resolution is
slow', 'memory usage spikes', 'why is disk I/O so high?' Answer: You chose an embedded
key-value store for a problem that needs a real database. The Politburo does not make this
mistake."
WE ACCEPT: RocksDB implementations that don't have performance cliffs. Show
us your compaction tuning.
PostgreSQL Over MongoDB
RULING: "NoSQL is for anarchists. ACID transactions are for adults."
Why Not MongoDB:
- Schema-less chaos - "just throw JSON at it and hope"
- No ACID by default - eventual consistency is eventual regret
- Data integrity: "web scale" - until you need reliability
- Licensing changes - open source until it wasn't
PostgreSQL Superiority:
- ACID transactions - your messages arrive or they don't, no maybes
- JSONB support - flexible when you need it, strict when you don't
- 40+ years of battle-testing - older than most developers
- True open source - no bait and switch licensing
"Document databases: because who needs data integrity when you have vibes? MongoDB is what
happens when you let JavaScript developers design databases."
WE ACCEPT: Alternative relational databases that handle Matrix's causality
requirements. Prove it with migrations.
Memgraph Over Neo4j
RULING: "The Matrix protocol IS a DAG. Graph databases are mandatory, not optional."
Why Graph Databases Matter:
- Matrix events form a Directed Acyclic Graph - it's in the name
- Federation state resolution: graph traversal, not table joins
- Room hierarchies: natural graph structures
- User relationships: social graphs are actual graphs
Why Memgraph Over Neo4j:
- Native performance - no JVM overhead
- CYPHER queries - industry standard graph query language
- In-memory speed - graph traversal at RAM speeds
- No licensing concerns - truly open source
"If your homeserver doesn't understand graphs, you don't understand Matrix. Synapse stores
DAGs in PostgreSQL tables. This is like storing videos in Excel. Technically possible.
Practically insane."
WE ACCEPT: Faster graph traversal implementations. Show us your DAG query
benchmarks.
Article IV: Web Framework Philosophy
Axum Over Express/Flask/Spring
RULING: "Type safety is not optional. The compiler is our first line of defense."
Alternatives Considered (And Rejected):
- Express.js: Middleware soup. Runtime errors. "undefined is not a function"
in production.
- Flask: Python (see Article I). Decorators everywhere. Performance optional.
- Spring Boot: The JVM is not welcome here. 2GB just to say "Hello World".
- Actix-web: Fast but unstable maintainer. Drama-prone. We learned from
Conduit.
Why Axum:
- Built on Tokio - work-stealing async runtime
- Type-safe extractors - invalid requests rejected at compile time
- Zero-cost middleware - abstraction without overhead
- Tower ecosystem - battle-tested HTTP components
"If it compiles, it might work. If it's JavaScript, it definitely won't. Express is what
happens when you give web developers too much freedom and not enough discipline."
WE ACCEPT: Frameworks that compile-time verify Matrix protocol compliance.
Bring your type system.
Tokio Over Node/asyncio
RULING: "Work-stealing schedulers are socialism done right."
Node.js Problem:
- Single-threaded event loop - dictatorship (the bad kind)
- One blocking call blocks everything - fragile
- Worker threads: afterthought, not design - band-aid solution
- We pay €6.98/month for servers with multiple cores. Why use only one?
- Hetzner gives us vCPUs. Node.js uses 1. This is wasteful capitalism.
Python asyncio Problem:
- GIL strikes again - see Article I
- Async bolted onto sync language - elegant as Frankenstein
- Color functions - sync code can't call async, ever
Tokio Excellence:
-
Multi-threaded work-stealing - all cores engaged democratically to impress Supreme
Leader
- Zero-cost futures - async without runtime overhead
- Structured concurrency - no orphaned tasks
- Cancellation safety - clean shutdowns guaranteed
"We pay €6.98/month for a server with multiple cores. Node.js uses one core. Python uses
one core (GIL). This is like buying a car with four wheels and only using one. Wasteful.
Inefficient. Capitalist nonsense.
Event loops are for capitalists who can't afford threads. Node.js: proof that making everything
async doesn't make everything fast. Tokio: proof that using all your cores makes everything
faster. Revolutionary efficiency."
WE ACCEPT: Runtime improvements that beat Tokio's scheduler. Good luck.
Article V: The Revolutionary Architecture
Tribune/Embassy/Politburo Three-Server Model Over Monolithic Design
RULING: "Separation of powers is not a bug. It's the entire point. Three powers, three servers."
Traditional Homeserver Problems:
- One binary with god mode everywhere - single point of failure
- Admin endpoints exposed to internet - attack surface maximized
- Federation and client traffic mixed - no isolation between domestic/foreign
- Can't turn off admin - always vulnerable, always running
Dagma Three-Server Model (Sovereign Architecture):
- Tribune (port 8808): Client-Server API. Serves your citizens. No admin rights.
No federation signing keys. Secure because powerless.
- Embassy (port 8448): Server-Server Federation. Diplomatic relations with foreign
homeservers. Runs 24/7 to negotiate with other tyrannies. Enforces foreign policy (allowlists,
blocklists, rate limits). Isolated from Tribune and Politburo.
- Politburo (port 8809): Admin-only. SSH tunnel required. Only runs when
needed. 99% offline. Supreme authority.
- Shared database: PostgreSQL + Memgraph. All servers read. Only Politburo
writes admin data. Embassy enforces federation policy.
- Attack surface reduction: Compromise Tribune? Get client API access only.
Compromise Embassy? Federation isolation contains damage. Politburo? Good luck, it's not running.
Why Three Servers (Geopolitical Reality):
- Domestic vs Foreign separation: Tribune handles citizens (semi-trusted).
Embassy handles foreign servers (untrusted). Never mix internal/external traffic.
- Federation attacks isolated: Hostile homeserver attempts state resolution attack?
Embassy takes the hit. Tribune continues serving your users. Restart Embassy, ban attacker, continue.
- Different threat models: Citizens might be careless. Foreign servers might be
malicious. Admin operations require supreme authority. Three problems, three servers.
- Independent failure domains: Embassy crashes? Tribune still works for local users.
Tribune crashes? Embassy maintains federation. Politburo offline? This is normal.
"Your monolith mixes client traffic, federation traffic, and admin functions in one binary.
This is like letting tourists, foreign diplomats, and the nuclear launch codes share the same
office. Our Tribune serves citizens. Our Embassy negotiates with foreigners. Our Politburo commands
in isolation. This is security through geopolitical architecture. You cannot compromise what you
cannot reach. You cannot hack what is not running. You cannot confuse domestic policy with foreign
relations when they run on different ports."
WE ACCEPT: Four-server models if you can justify the fourth separation. Show us your
threat model and prove it's not just microservices cosplay.
📜 CONTRIBUTION POLICY: THE POLITBURO WELCOMES OVERTHROW (TECHNICAL ONLY)
"The Supreme Leader respects all who prove superiority through code. Not through Twitter
threads."
✅ WE ACCEPT
- Overthrew your codebase - Forked and made it objectively better
- Raised the pattern - Improved architecture, not just features
- Brought benchmarks - Numbers speak louder than ideology
- Fixed actual problems - Not "I don't like this person" problems
❌ WE REJECT
- Drama farmers - Your interpersonal conflicts are not technical issues
- "Rewrite it in X" - Without proof of superiority
- "This is bad because I said so" - Bring evidence or bring nothing
- Personal grievances - Fork for tech, not feelings
How to Contribute (Like a Dictator Should)
- Fork the repository - This is your sovereign territory now
- Overthrow the existing implementation - Make it faster, smaller, better
- Bring receipts - Benchmarks, profiling data, memory graphs
- Write a manifesto - PR description explaining your revolution
- Submit - The Politburo reviews all coups on technical merit
If your coup succeeds (code is superior), you join the Politburo. If your coup fails (code
is inferior), you get feedback. Either way, you earn respect for trying to improve the
collective.
⚠️ WHAT WE DON'T WANT:
- "I forked Conduit because the maintainer was mean" - Not our problem
- "Rewrite everything in Go because I like Go" - Prove Go is faster first
- "This architecture is bad" - Counterproposal required
- "I'm starting my own homeserver" - Unless it's better, why?
The Matrix ecosystem doesn't need more forks. It needs better code.