We build resilient, functional, decentralized infrastructure because idealistic systems collapse under their own weight. The RED Collective is a non-profit organization dedicated to engineering decentralized, sovereign knowledge networks. We do not invent abstract, gamified theories; we implement cold execution.

True freedom of information requires absolute decentralization. Existing platforms fail because they rely on centralized master domains, leaving them vulnerable to legal suppression, database corruption, and internal censorship.

Project R.E.D shifts absolute agency to the user. If a user disagrees with a node maintainer, or if a centralized group of collaborators refuses a modification, the user can host their own data on their own infrastructure. No single entity — not even the RED Collective itself — can exercise control or censorship over an independent node.

Rather than burning capital to develop easily gamed voting algorithms or vulnerable internal databases, we outsource the social curation layer to established networks. We deliberately use platforms optimized for engagement and bot defense — Reddit, Discord, and similar networks — and redirect them toward technical peer review. Communities vote, verify credentials, and file complaints through established, human-verified infrastructure. We do not build an ecosystem to capture your attention; we redirect your attention toward collective literacy.

A stateless, high-performance Go HTTP server that compiles raw Markdown files into verifiable, cryptographically-signed knowledge bases. Zero database required for content; optional SQLite for operational metadata only.

Core features:

• Ed25519 cryptographic verification — every article is signed and verified against a trusted contributor list; hash mismatches are caught on every request
• Challenge-response peer federation — nodes discover, announce, and re-register each other via replay-proof nonce-based handshakes; no centralized registry
• Instant mirroring — import content from GitHub, archives, or raw URLs; the engine reconstructs the filesystem hierarchy and serves it without restart
• Admin API — protected by constant-time token comparison; manage peers, contributors, imports, and startup sync configurations
• Stateless architecture — all content served directly from disk; containers replicate instantly across alternative IP addresses or cloudflared tunnels
• Built-in federation modes — upstream (read-only, invisible), downstream (pull from you, you announce URL changes), mirror (bidirectional sync)

Licensed under AGPL-3.0 with binding attribution term.

A TypeScript + Go plugin for Obsidian that cryptographically signs Markdown vault files with Ed25519 directly inside your note-taking environment. The TypeScript layer manages all UI, modals, and vault metadata. The bundled red-signer Go binary handles all cryptographic operations locally — no cloud calls, no key escrow.

Core features:

• Zero-friction signing — sign notes directly in Obsidian via ribbon icon, editor menu, or command palette without leaving your vault
• Local Ed25519 signing — cryptographic operations run entirely on your machine; your private key never leaves ~/.red-signer/
• Branch classification — organize and immutably classify knowledge by topic and domain; first signer becomes the canonical branch author, locking classification against unauthorized change
• Real-time status — status bar displays ✓ Signed, ⚠ Modified, or Unsigned by comparing live file hash against the signed manifest on every keystroke
• Cross-platform binaries — ships with platform-specific red-signer binaries for Linux, macOS (Intel + Apple Silicon), and Windows; correct binary is auto-detected at load time

Licensed under AGPL-3.0 with binding attribution term.

Platforms like Stack Overflow, Wikipedia, and Discord represent billions of dollars of centralized infrastructure. They are trivial targets for:

• Corporate lawfare — a single takedown notice removes an entire knowledge repository
• State suppression — a regime blocks one domain; all mirrors vanish
• Platform decay — when the company pivots, knowledge becomes collateral damage
• Internal corruption — a bad-faith moderator or policy change spreads across the entire network instantly

Project R.E.D eliminates this vulnerability by design. There is no master domain. If one node is shut down, the network persists. If one operator is compromised, the cryptographic signatures prove it.

We do not waste resources on distributed consensus, proof-of-work, or token economics. Instead:

• Every article is signed with the author's Ed25519 key and verified on every request
• Trust is based on a web-of-trust model: you decide which contributors to trust
• Your local client aggregates content from your trusted network and surfaces the best version based on network consensus

No token, no mining, no Google sign-up. Just cryptography and trust.

The tech industry packages existing technologies into complex configurations and sells them as grand inventions. We reject this. We make deliberate use of proven infrastructure instead of building proprietary, vulnerable layers from scratch.

• Go — stateless runtime compiling to a single static binary; zero VM overhead, maximum concurrency
• Ed25519 + SHA-256 — proven, auditable algorithms; no novel crypto
• SQLite — zero external dependencies; schema is version-controlled and append-only; the registry can be wiped and rebuilt from the filesystem at any time
• Obsidian — one of the best local-first Markdown editors in the world; we leverage it rather than building a custom authoring environment from scratch
• AGPL-3.0 — the license that protects decentralized software from being absorbed and closed

1. Client requests an article
2. Server loads the .md file and computes its SHA-256 hash
3. Server looks up the file in the local signer.db manifest and verifies the Ed25519 signature
4. Server checks whether the signing public key is in the trusted contributors list
5. Server renders the article with a verification badge (✅ Verified, ⚠️ Unverified, or ✗ Invalid Signature)
6. The full SHA-256 hash is displayed in the footer for manual verification

Verification requires no database — it is purely file-based, stateless, and auditable.

Nodes operate in three modes:

• Upstream — read-only; invisible to the network; you pull content, no one knows you exist
• Downstream — others pull from you; when your URL changes, you announce the new address via a challenge-response handshake
• Mirror — bidirectional sync with other nodes

The announce handshake is replay-proof:

1. Node A requests a fresh nonce from Node B
2. Node A signs nonce|new_url with its private key
3. Node A submits the signature; Node B verifies it against the registered public key
4. The nonce is single-use and expires in 5 minutes, preventing replay attacks
5. The signature is bound to the new URL and cannot be reused for a different address

Nodes behind restrictive firewalls can announce themselves via cloudflared tunnels. The engine automatically re-announces the new URL after a tunnel restart using this same handshake.

RED-Feather separates concerns cleanly: TypeScript handles the Obsidian UI layer; Go handles the cryptographic backend. Each layer does exactly one thing and is auditable independently.

docker run -p 8080:8080 \
  -v /data/knowledge:/data \
  -e RED_ADMIN_TOKEN='your-secure-token' \
  red-collective/red-engine

Run a 2-node federation, a regional cluster, or a global mesh. Nodes discover each other, sync content asynchronously, and gracefully handle network partitions.

1. Clone RED-Engine
2. Place your Markdown content in the data/ directory
3. Run go build -o red ./cmd/red && ./red
4. Access the node at http://localhost:8080
5. Manage peers, contributors, and imports at http://localhost:8080/-/admin

1. Install RED-Feather in Obsidian
2. Use the plugin to sign notes with your Ed25519 key
3. Export the signed vault to a RED-Engine node

See DEVELOPER_GUIDE.md for architecture deep-dives, schema documentation, and contribution guidelines.

RED-Engine and RED-Feather are actively developed and approaching production-readiness.

Roadmap:

• Expanded test coverage on federation handshake and signature verification
• Structured logging and observability (Prometheus metrics)
• Rate limiting and security hardening for the admin API
• Multi-node federation demo and deployment guides
• Vue 3 + TypeScript frontend rebuild

Both RED-Engine and RED-Feather are licensed under the GNU Affero General Public License v3.0 (AGPL-3.0).

Per AGPL-3.0 Section 7(b), an additional attribution term applies: any copy, modified version, or derivative — including a modified version operated as a network service — must preserve the credit "Powered by RED Collective." linked to https://github.com/RED-Collective.

This credit may not be removed and is a condition of the license. See NOTICE.md in each repository for the full legal terms.

• GitHub: https://github.com/RED-Collective
• RED-Engine: https://github.com/RED-Collective/RED-Engine
• RED-Feather: https://github.com/RED-Collective/RED-Feather

Issues, pull requests, and feature discussions are welcome in each repository. The network grows one honest node at a time.

© 2026 RED Collective. Content licensed under Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0). Software licensed under AGPL-3.0.