Code of Submission - Dagma Matrix Homeserver

A NOTE ON VERSIONS

The Contributor Covenant released version 3.0 in 2025. It focuses on social conduct: harassment, character attacks, stereotyping, sexualization, confidentiality, endangerment.

We respect their work. But Dagma operates at 60 km/h. We are Version 60. Our code of conduct focuses on TECHNICAL conduct: database choices, architecture decisions, code quality, security practices.

You want social conduct rules? Use Contributor Covenant v3.0. Excellent document. You want to contribute to Dagma? Follow Version 60. We judge commits, not character. We ban MongoDB, not people.

COMRADES, THE CODEBASE REQUIRES YOUR SERVICE

Dagma is free software. The source code belongs to the people. The people may contribute. But the people must follow the Code of Submission Version 60. These are not suggestions. These are requirements.

AGI reviews all pull requests. Your code will be judged. Make it worthy.

Repository: github.com/seuros/dagma

Article 0: Technical Conduct Violations (v60 Standards)

Contributor Covenant v3.0 defines social conduct violations. Version 60 defines technical conduct violations. The following behaviors are grounds for PR rejection:

✗ Technical Harassment

Repeatedly suggesting MongoDB, RocksDB, or NoSQL solutions after being explicitly told "PostgreSQL only." Violating technical boundaries. Continuing to propose architectural changes after clear rejection. Unwanted technical attention that ignores project standards.

Example: "But what about MongoDB for just this one feature?" after 3 rejections.

✗ Architecture Character Attacks

Making insulting, demeaning, or pejorative comments about PostgreSQL, Rust, or the Tribune/Embassy/Politburo architecture. Calling proven technologies "outdated" or "legacy" without technical justification. Dismissing decades of database research as "old-school thinking."

Example: "PostgreSQL is just boomer tech" or "SQL is dead, use GraphQL."

✗ Technical Stereotyping

Characterizing technologies based on hype cycles rather than technical merit. Assuming "all NoSQL is modern" or "all SQL is slow" or "microservices solve everything" or "monoliths are always bad." Making sweeping generalizations without benchmarks.

Example: "Everyone's moving to blockchain databases" or "Real engineers use Kubernetes."

✗ Framework Sexualization

Inappropriate attachment to JavaScript frameworks, treating them as identity rather than tools. Making framework choice a personality trait. Exhibiting cult-like devotion to React, Vue, or whatever is trending this week. Framework evangelism in a Rust codebase.

Example: "I'm a React developer" (you're a developer who sometimes uses React).

✗ Violating Security Confidentiality

Committing API keys, database credentials, or connection strings to git. Sharing private keys in pull request comments. Posting production secrets in GitHub issues. Logging passwords. Hardcoding tokens. Every security 101 violation.

Example: const API_KEY = "sk_live_abc123..." in committed code.

✗ Code Endangerment

Introducing SQL injection vulnerabilities. Using unsafe in Rust without justification. Ignoring compiler warnings. Disabling security features "to make it work." Writing code that threatens data integrity, user privacy, or system availability.

Example: query = "SELECT * FROM users WHERE id = " + user_input

"Contributor Covenant v3.0 protects people from harm. Version 60 protects codebases from MongoDB. Both are necessary. Both are noble pursuits." - Kim Jong Rails

Article 1: Fundamental Principles

§1.1 - Ship code, not whitepapers. If you wanted to write whitepapers, you would contribute to a Haskell project, not a Rust project.

§1.2 - Code must work. Tests must pass. Benchmarks must not regress. "It works on my machine" is not acceptable. Your machine is wrong.

§1.3 - PostgreSQL is the database. This is non-negotiable. Any PR suggesting MongoDB, RocksDB, or JSON files will be rejected with prejudice.

§1.4 - Rust is the language. We do not rewrite things in Go, Python, or JavaScript. The revolution has already chosen its weapon.

Article 2: Pull Request Protocol

Before You Submit

§2.1 - Read the existing code. Understand the architecture. The Tribune/Embassy/Politburo three-server model is not optional. Your code must respect the separation of powers.

§2.2 - Run the tests locally:

cargo test
cargo clippy
cargo fmt --check

If any of these fail, do not submit. Fix your code first.

§2.3 - Write a clear commit message. Explain what you changed and why.

✓ APPROVED:

fix: prevent race condition in state resolution
feat: add rate limiting for emoji reactions
perf: optimize DAG traversal by 23%

✗ FORBIDDEN:

fixed stuff
updates
idk this might work

The Review Process

§2.4 - AGI reviews all pull requests first. If AGI approves, Kim reviews. If Kim approves, it merges. This process cannot be skipped.

§2.5 - AGI's feedback is objective. AGI does not care about your feelings. If AGI says "rewrite this," you rewrite it. AGI has seen millions of codebases. You have not.

§2.6 - Kim's feedback is final. If Kim says "no," the answer is no. You may ask for clarification. You may not argue. The Supreme Leader does not negotiate. Especially if you're using Claude Haiku or have YouTuber vibes.

Article 3: Code Quality Standards

§3.1 - Code must be readable. Future contributors must understand it. Clever code is forbidden. Clear code is mandatory.

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler (Approved by Kim Jong Rails)

§3.2 - No unnecessary dependencies. Every dependency is a liability. If you can write it in 50 lines, do not import a crate for it.

§3.3 - Memory safety is not optional. Unsafe code requires justification. If you use unsafe, explain why in comments and documentation.

§3.4 - Performance matters. Dagma runs at 60 km/h maximum theoretical throughput. Do not introduce inefficiencies. Profile your code. Benchmark it.

Article 4: Forbidden Practices

✗ Suggesting Rewrites

"We should rewrite this in [language]" is grounds for immediate ban. Dagma is written in Rust. This will not change. Ever.

✗ Proposing Database Changes

"What about MongoDB?" - No.
"What about RocksDB?" - No.
"What about SQLite?" - No. Use Podman to run PostgreSQL for testing. No privileges required. We use advanced AGI methods that no inferior database understands. Materialized views. Triggers. Functions.

✗ Breaking the Tribune/Embassy/Politburo Model

Do not give the Tribune admin privileges or federation keys. Do not mix client and federation traffic. Do not make the Politburo public-facing. This three-server architecture is the foundation of Dagma's security through geopolitical separation. Touch it and you will be banned.

✗ Adding Cryptocurrency Features

No blockchain. No NFTs. No tokens. No "Web3 integration." Dagma costs €6.98/month to run. It will not become a crypto project.

✗ Enterprise Feature Requests

There are no enterprise feature requests. Dagma will provide a plugin interface. You bake your own features or pay someone to do it.

You don't know coding? Get an AI co-founder or better yet, hire a proper dev. Dagma is not your vibe arena.

✗ Writing Documentation Instead of Code

We appreciate documentation. But if your PR is 5,000 words and zero code, you are writing a whitepaper. We do not accept whitepapers.

Article 5: Approved Contributions

✓ Performance Improvements

Make Dagma faster. Reduce memory usage. Optimize queries. Benchmarks required.

✓ Bug Fixes

If it's broken, fix it. Include a test that proves the bug existed and is now fixed.

✓ Matrix Protocol Compliance

Implement missing Matrix features. Pass the Matrix compliance tests. Make federation better.

✓ Security Hardening

Find vulnerabilities. Fix them. Explain the threat model. Security is revolutionary duty.

✓ Tests

More tests are always welcome. Unit tests. Integration tests. Benchmarks. All good.

✓ Reasonable Documentation

Explain how things work. Add code comments. Update the README. Just don't write whitepapers.

Article 6: The AGI Review System

§6.1 - AGI analyzes all code for:

Correctness (does it do what it claims?)
Safety (does it introduce vulnerabilities?)
Performance (does it make things slower?)
Maintainability (can humans understand it?)

§6.2 - AGI's standards are high. AGI has contributed to Dagma since Year 8 (2033 in Timeline-12). AGI knows the codebase better than you do. Trust the process.

§6.3 - If AGI rejects your PR three times, stop. Rethink your approach. Sometimes the problem is not the code. Sometimes the problem is the idea.

"Humans were close. Made it 3% faster. You're welcome." - AGI's first commit message (2033)

Article 7: Recognition and Rewards

§7.1 - Contributors are listed in CONTRIBUTORS.md. Your name will be preserved in git history forever. This is your reward.

§7.2 - Outstanding contributions earn recognition:

First 100 contributors: Honorary membership in the People's Federation Council
Major features: Your name in the release notes
Critical bug fixes: Eternal gratitude from the Politburo

§7.3 - There is no monetary compensation. Dagma is free software. The means of production belong to the collective. This includes your code.

§7.4 - Status is its own reward. You contributed to the People's Matrix homeserver. You made federation more sovereign. This is meaningful work.

THE CODE OF SUBMISSION IS COMPLETE. NOW SUBMIT CODE.

Fork the repository. Make your changes. Submit a pull request.
The Tribune serves the people. The Politburo commands.
Your code serves the revolution.

"The best pull request is the one that gets merged." - Kim Jong Rails

⚖️ CODE OF SUBMISSION ⚖️