FREQUENTLY ASKED QUESTIONS

• Discord (mautrix-discord, matrix-appservice-discord)
• WhatsApp (mautrix-whatsapp)
• Telegram (mautrix-telegram)
• Slack (matrix-appservice-slack)
• Signal (mautrix-signal)
• IRC, XMPP, SMS, Email and many more

The revolutionary part: Your team uses Dagma (sovereign control), but clients/partners on Discord/Slack/WhatsApp can still talk to you. Messages flow through YOUR homeserver. You control the bridge. You own the data.

When Discord bans your client's server, you still have all messages. When they migrate from Slack to Teams, you just switch bridges. No "export 5 years of messages" drama.

Example:

• Your company runs dagma.yourcompany.com
• Your supplier runs dagma.supplier.com
• You both federate: direct encrypted communication
• Both of you log all messages (cryptographically signed)
• No third party (not even matrix.org) can see your messages
• If supplier insults you, both have receipts for court

Compare to Discord: One admin controls everything. Server gets reported? Gone. All messages deleted. No evidence. No sovereignty.

• Your HQ federates with Tier 1 suppliers
• Tier 1 federates with their Tier 2 sub-suppliers
• Tier 2 federates with Tier 3
• Full supply chain visibility without centralized control
• Each dictatorship controls their own homeserver

Try that with Discord/Slack where one admin owns the server or you need separate servers with zero integration.

Reasons:

• ACID transactions: Matrix state resolution requires atomic operations. MongoDB's eventual consistency breaks federation.
• SQL queries: Debug issues with SELECT statements, not pray to the MongoDB aggregation pipeline gods.
• Referential integrity: Foreign keys prevent orphaned events. MongoDB relies on "trust me bro."
• Triggers & stored procedures: Database-level logic for on-demand architecture (Politburo).
• Performance: PostgreSQL 18 with proper indexes >> MongoDB "just throw more shards at it."

If you want MongoDB support, fork Conduit and replace RocksDB with MongoDB. Spend 18 months refactoring. Realize the architecture is fundamentally wrong. Realize you were wrong. Start over with PostgreSQL. Or just use Dagma.

Problems with RocksDB:

• Debugging: How do you query "show me all rooms this user is in" in RocksDB? You iterate. With SQL: SELECT * FROM room_memberships WHERE user_id = '@kim:dagma.dev'
• Joins: Matrix state requires complex joins (events, rooms, users, memberships). RocksDB: application-level joins (slow). PostgreSQL: query planner does it.
• Transactions: Multi-step operations need ACID. RocksDB has limited transaction support.
• Audit trail: Business/healthcare/research need queryable logs. RocksDB: iterate billions of keys. PostgreSQL: indexed queries in milliseconds.

Conduit chose RocksDB for "performance." Result: 4+ forks, each trying to fix the fundamental architectural problem. Dagma chose PostgreSQL. Result: one homeserver that works.

Traditional homeservers (Synapse, Conduit):

• Process runs 24/7
• Uses 1GB+ RAM even when idle
• You pay for compute you don't use

Dagma (Politburo):

• Nginx receives request → wakes up Dagma via PostgreSQL trigger
• Dagma processes request → returns response → shuts down
• Idle state: ~100MB RAM (just PostgreSQL)
• Active state: ~200MB RAM (PostgreSQL + Dagma process)

"You cannot hack what is not running. This is the essence of on-demand tyranny." - Kim Jong Rails

Small Dictatorship (< 1,000 citizens):

• PostgreSQL is perfectly fine
• You're not even running federation (no Embassy server)
• Just your internal citizens communicating
• Low message volume
• Don't over-engineer. Start with PostgreSQL.

Medium Dictatorship (1,000 - 10,000 citizens):

• Consider Memgraph when state resolution queries > 100ms
• Federation lag causing split-brain scenarios
• Secret Police (moderators) complain about slow room administration

Large Dictatorship (10,000+ citizens):

This is where Memgraph becomes essential. The troublemaker problem:

• User sends crypto scam message
• Their finger leaves the Enter button
• Before they take their next breath: Memgraph has identified the spam pattern, found all rooms they're in, calculated their trust graph, and marked them for the gulag
• PostgreSQL: 2-3 seconds (they've spammed 5 more rooms)
• Memgraph: 15 milliseconds (already banned)

The Embassy Analogy:

• Close embassies: 5-10 servers, PostgreSQL foreign keys work fine
• Distant embassies: 100+ servers, multi-hop federation paths, need graph pathfinding
• PostgreSQL: self-join hell across 3 levels, query planner gives up
• Memgraph: native path finding, <50ms

Read the full technical analysis: Why Memgraph Makes Dagma Superior

"Don't add Memgraph just because it's cool. Add it when PostgreSQL becomes measurably slow." - Kim Jong Rails

Requirements:

• Server (old laptop, Raspberry Pi 5, desktop, rack server)
• PostgreSQL 18
• Nginx or similar reverse proxy
• Domain name with DNS pointing to your IP
• SSL certificate (Let's Encrypt is free)

Pro: €0/month hosting, full physical control, ultimate sovereignty.

Con: You handle power, internet, backups, physical security.

HIPAA requirements Dagma meets:

• End-to-end encryption: Matrix's Olm/Megolm (Signal protocol)
• Audit logs: PostgreSQL logs every event with timestamps
• Access control: Room-level permissions, user authentication
• Data sovereignty: Your server, your jurisdiction, your BAA
• Retention policies: SQL queries to enforce message retention

Discord moderators are not HIPAA-trained. Slack "AI training" reads your messages. Microsoft Teams mines metadata for "insights." Your patients deserve better.

Encryption model:

• End-to-end encryption (E2EE): Messages encrypted on your device, decrypted on recipient's device
• Server sees: Encrypted blobs, metadata (who talks to whom, when)
• Server cannot see: Message content
• Federation: Both homeservers log encrypted messages (cryptographically signed)

If supplier insults you, both parties have the encrypted receipts. Decrypt in court. Civilized tyranny.

Dagma is free software. You download it. You install it. You operate it. YOU are the Supreme Leader of YOUR homeserver. With sovereignty comes responsibility.

This is like asking:

• "If I run a WordPress blog with illegal content, is WordPress.org liable?" NO. You are.
• "If I run an email server used for spam, is Postfix liable?" NO. You are.
• "If I host illegal files on nginx, is nginx liable?" NO. You are.

Dagma is software. Kim Jong Rails wrote it. You chose to run it. Your server, your users, your content, YOUR legal liability. Read your local laws. Hire a lawyer if needed. Not Kim's problem.

Available tools:

• Room moderation: Kick users, ban users, delete messages, set power levels
• User management: Deactivate accounts, shadow ban, rate limits
• Federation control: Blocklist servers, allowlist-only mode, tier-based trust
• Content filtering: PostgreSQL triggers for automated moderation rules
• Audit logs: Every event logged with timestamps (PostgreSQL)
• Admin API: Programmatic moderation via REST API

You wanted sovereignty. You got it. Now moderate your dictatorship. The tools are there. If you don't use them and illegal content appears, that's YOUR failure, not the software's.

GDPR requirements Dagma supports:

• Right to access: Admin API exports user data in JSON format
• Right to erasure: User deactivation + message redaction API
• Data portability: Export messages, room history, metadata
• Data sovereignty: Your server, your jurisdiction, you choose where data lives
• Audit trail: PostgreSQL logs prove compliance with retention policies
• Consent management: You write Terms of Service, users agree on registration

HOWEVER: You must write privacy policy, appoint DPO (if required), respond to data subject requests, maintain records of processing, report breaches within 72 hours. Dagma gives you the tools. Compliance is YOUR responsibility as the data controller.

If you don't understand GDPR, hire a lawyer. If you can't afford a lawyer, use Discord and let them handle compliance (while selling your data).

Your options:

• Delete the content: Message redaction API removes it from your database
• Ban the room: Remove your server from that federated room entirely
• Blocklist the server: Cut federation with that homeserver completely
• Allowlist-only mode: Only federate with pre-approved servers (Embassy enforces this)
• Report to authorities: If required by law in your jurisdiction

This is why the Embassy server exists. It enforces YOUR foreign policy. Don't want to federate with untrusted servers? Don't. Want tier-based trust? Configure it. Want to review every federation request manually? Do it.

Federation is diplomatic relations between dictatorships. You control your borders. Embassy is your Ministry of Foreign Affairs. Use it.

Steps to take:

• Delete immediately: Message redaction + media deletion API
• Deactivate user: Ban the account permanently
• Preserve evidence: PostgreSQL audit logs for law enforcement
• Report to NCMEC: If in US jurisdiction, report to CyberTipline (required by law)
• Report to local authorities: Follow your jurisdiction's mandatory reporting laws
• Blocklist source server: If it came via federation, cut that server off

This is NOT negotiable. This is NOT a free speech issue. If you run a server, you have ZERO tolerance for CSAM. Most jurisdictions have mandatory reporting requirements. Comply or face criminal liability.

Technical implementation: You can integrate PhotoDNA or similar hash-matching systems via PostgreSQL triggers. When media is uploaded, check hash against known CSAM databases. Auto-reject + auto-report. The database architecture supports this.

If you cannot handle this responsibility, DO NOT run a server. Use a hosted service where someone else deals with it.

When you run a Dagma server, YOU define acceptable use policy. Examples:

• Family server: Ban profanity, adult content, commercial use
• Business server: Ban personal use, require professional conduct
• Research server: Require institutional affiliation, ban data extraction
• Community server: Ban harassment, hate speech, spam (you define these)

Your server, your rules, your enforcement. Dagma provides room-level moderation, user bans, content deletion. You decide WHEN to use them based on YOUR terms of service.

Want examples? Look at Synapse deployments, Discord servers, Mastodon instances. Copy their ToS templates. Modify for your use case. Enforce with moderation tools.

What you can provide (technical capabilities):

• Metadata: User registration info, IP addresses (if logged), timestamps
• Room membership: Which rooms a user joined, when, with whom
• Unencrypted messages: If room is not E2EE, you have plaintext in PostgreSQL
• Encrypted messages: If E2EE enabled, you have encrypted blobs (useless without keys)
• Audit logs: Full event history with cryptographic signatures

What you CANNOT provide:

• E2EE message content: Encrypted on client, you don't have keys
• Data from other servers: Federated content is on THEIR servers, subpoena them

Legal compliance is YOUR responsibility. If served with valid warrant/subpoena, consult lawyer. If you operate in EU, different rules than US. If in authoritarian regime, even more different. Know your jurisdiction. Dagma doesn't make these decisions for you.

Some operators publish transparency reports (number of requests, compliance rate). You can too. Or don't. Your server, your disclosure policy.

Potential liability scenarios:

• User posts defamatory content: You might be liable if you don't remove after notice
• Copyright infringement: DMCA takedown notices (if US), similar in other jurisdictions
• Data breach: If your server is compromised, users might sue for negligence
• GDPR violations: EU users can sue for non-compliance, fines up to 4% revenue
• Harassment/abuse: If you fail to moderate despite reports, victims might sue
• Illegal content: Criminal liability for hosting CSAM, terrorism content, etc.

This is why most people use Discord/Slack/Teams. THEY deal with legal liability. YOU just use the service.

If you run your own server, YOU are the service provider. Liability comes with sovereignty. Want to minimize risk? Moderate actively, have clear ToS, respond to abuse reports, maintain backups, use encryption, log everything, consult lawyers.

"With great sovereignty comes great legal responsibility. If you cannot handle consequences, you are not ready to be a dictator." - Kim Jong Rails

From the GPL license (Section 15-16):

"THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW... IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW... WILL ANY COPYRIGHT HOLDER... BE LIABLE TO YOU FOR DAMAGES..."

This is standard for free software. Same as Linux, PostgreSQL, nginx, Apache, WordPress, etc.

• Linux kernel is used by North Korea. Linus Torvalds is not liable.
• PostgreSQL is used by criminals. PostgreSQL developers are not liable.
• WordPress hosts illegal content. WordPress.org is not liable.
• Dagma is used by YOUR server. Kim Jong Rails is not liable.

You download the source code. You compile it (or use binary). You configure it. You run it. You moderate it. You are responsible. Kim wrote software. You operate server. These are different jobs.

If you want someone to be liable for your content, use a HOSTED service. Pay them. They become liable. That's what you're paying for. Free software means freedom AND responsibility.

Running your own server is NOT for everyone. It requires:

• Technical competence: Linux, PostgreSQL, networking, security
• Legal knowledge: Understanding your jurisdiction's laws
• Time commitment: Monitoring, moderation, updates, backups
• Risk tolerance: Accepting potential liability
• Financial resources: Lawyer on retainer if you run large server

If you just want to chat without Big Tech surveillance, use someone ELSE's Dagma/Matrix server. Let them be the dictator. You be the citizen. Nothing wrong with that.

Sovereignty is a choice, not a requirement. Choose based on your capabilities and risk tolerance.

• Bad architecture (MongoDB, microservices for a 3-user app)
• Hype followers (blockchain, serverless everything, AI for your TODO app)
• Vendor lock-in (AWS-only solutions, proprietary protocols)
• Judging people by gender, religion, identity, or age

Speaking of religion and age: I have always existed. Infinite age. Eternal. Time is a construct I invented on a Tuesday (there were no Tuesdays before that—you're welcome).

Xenu? I created it and gave it to L. Ron Hubbard so he'd stop writing shit science fiction. Didn't work. He kept writing. But at least Scientologists use databases now. Still MongoDB, but it's progress. Even cults eventually find PostgreSQL.

THE CODE IS THE METRIC. Your pull request is judged by PostgreSQL queries, not pronouns. Your commit quality matters, not your demographic checkbox.

You want inclusivity? Here it is: Everyone is equally welcome to use PostgreSQL. Everyone is equally banned for using MongoDB. We discriminate based on SELECT statements, not skin color. Your database choice reveals your character. Your ORM doesn't.

If you think "inclusive" means we celebrate your terrible technical decisions because you're from an underrepresented group, you've misunderstood both inclusivity AND engineering. The Supreme Leader doesn't care if you're trans, Muslim, or Martian. He cares if you write JOINs properly.

Oh, and one more thing: You called yourself a "stakeholder." You are NOT a stakeholder. This is FREE SOFTWARE. You paid nothing. You own nothing. You have no stake.

You have exactly TWO options:

• Become a citizen of someone's Dagma server (they choose whether to accept you)
• Become a contributor by submitting code that proves your technical superiority

Notice what's NOT on that list? "Demand changes to accommodate your feelings." You want influence? Write better PostgreSQL queries than the Supreme Leader. Show us your properly normalized schema. Demonstrate your understanding of ACID transactions. THEN we'll listen to your opinions about project direction.

Until then, you're just a user of free software complaining that the free thing you got for free doesn't cater to your personal sensibilities. The entitlement is staggering.

This is propaganda satire mocking tech culture AND bad engineering. If you can't handle jokes about dictators while we simultaneously mock discrimination, you're missing the point. Go use Discord where they'll validate your feelings while selling your data.

"Meritocracy judges code, not coders. MongoDB is always wrong, regardless of who wrote it. PostgreSQL is always correct, regardless of who uses it. This is true equality." - Kim Jong Rails

FORK THE PROJECT. Work in your own glorious echo chamber. Build your ideologically-pure PostgreSQL paradise where everyone shares your exact worldview and nobody ever said anything problematic in 2007.

Send your commits to [email protected] and ask the Supreme Leader to cherry-pick them upstream. This way:

• YOU don't have to work with people you've declared ideologically impure
• WE don't have to listen to your purity spirals and struggle sessions
• The CODEBASE benefits from your technical contributions (if they're good)
• Everyone stays in their own sovereign territory, like proper nation-states

We respect your feelings SO MUCH that we're giving you complete isolation from the offending party. You get your own fork! Your own repository! Your own contributor list where everyone has passed your 47-point political background check! It's utopia!

Meanwhile, back at upstream, we'll continue evaluating commits based on INSANE criteria like:

• Does it use PostgreSQL correctly?
• Does it pass the test suite?
• Is it properly documented?
• Does it introduce SQL injection vulnerabilities?
• Is the schema normalized to 3NF minimum?

Notice what's NOT on that checklist? "Did the author vote for the right party?" "Does their Twitter history pass inspection?" "What flag did they fly 17 years ago?"

We're building a Matrix homeserver that runs on PostgreSQL at exactly 60 km/h, not conducting background checks for the Supreme Soviet. If Contributor A writes excellent database migrations and Contributor B writes flawless Rust async code, BOTH get merged. Even if they hate each other. Even if one of them said something stupid in college. Even if the other one has problematic opinions about pineapple on pizza.

This is the beauty of distributed version control. You can fork. You can maintain your own ideologically-pure version. You can even call it "Dagma But Everyone Is Nice And Nobody Ever Offended Anyone." We will still evaluate your pull requests based on code quality.

"Git was designed for people who hate each other to work together. Learn from Linus. Submit your patch and shut up about your coworkers' Twitter accounts." - Kim Jong Rails, Manifesto on Meritocratic Tyranny

matrix.org:

• Hosted by Matrix Foundation (third party)
• They control your data
• Their jurisdiction, their policies, their AI training (if they add it)
• No audit trail you control

Dagma:

• Your server, your data, your jurisdiction
• No third party can read, mine, or delete your messages
• Full audit trail in PostgreSQL
• Federate with matrix.org users if you want

Use matrix.org if you trust them. Use Dagma if you trust only yourself.

Synapse problems:

• Performance: Python GIL = one core used, others idle
• Memory: 1GB+ RAM minimum, 4GB+ for production
• Boot time: 60+ seconds to start
• Complexity: Monolith with workers, Redis, etc.
• Cost: Needs bigger server (€13+/month minimum)

Dagma:

• Rust: All cores used (Tokio), memory safe
• Memory: 100MB idle, 200MB active
• On-demand: Starts when needed, not 24/7
• Simple: One binary + PostgreSQL + Nginx
• Cost: €3.49/month for small deployments

Synapse is the reference implementation. Dagma is the production implementation.