WAIT — Stale — last commit 1y ago

• 29+ active contributors
• Apache-2.0 licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 56% of recent commits
• ⚠ Scorecard: marked unmaintained (0/10)

_{Computed from maintenance signals — commit recency, contributor breadth, bus factor, license, CI, tests, cross-checked against OpenSSF Scorecard}

Dendrite is a second-generation Matrix homeserver written in Go that provides an efficient, scalable alternative to Synapse for federated real-time messaging. It implements the full Matrix specification with concurrent support for features like room federation, end-to-end encryption, and application services, designed to run on small deployments (10s-100s of users) or P2P nodes on mobile/browser via Pinecone or Yggdrasil overlays. Monolithic structure with functional microservices: appservice/ handles external integrations, roomserver/ (not visible but core), federationapi/, clientapi/, and mediaapi/ are separate services communicating via NATS broker; build/gobind-pinecone and build/dendritejs-pinecone provide mobile/WASM bindings; shared pkg/ utilities across all services.

Matrix server administrators deploying federated chat infrastructure, mobile/embedded developers building P2P Matrix clients via gobind bindings, and contributors maintaining a production-grade homeserver written in Go who want better performance and reliability than Synapse.

Beta software actively maintained but moving to element-hq/dendrite: implements the full Matrix spec, passes sytest and complement test suites, has PostgreSQL/SQLite support with schema migrations, and CI/CD via GitHub Actions. However, it lacks high-availability clustering and has not been battle-tested at massive scale—suitable for early adopters but not yet for very large deployments.

Maintenance moved from matrix-org to element-hq in late 2023, creating a fork risk; dependency on specialized networking libraries (Pinecone, Yggdrasil) adds operational complexity; no obvious open backlog visible in file structure; relies on gomatrixserverlib and custom fork of go-sqlite3-js for critical functionality. Check element-hq/dendrite for active development.

Repository is archived at matrix-org; active development continues at element-hq/dendrite. The original repo shows Docker compose demos, Kubernetes/Helm workflows, and P2P transport options (Pinecone, Yggdrasil) in .github/workflows/. Last visible commits likely include feature work on federation and mobile bindings.

git clone https://github.com/matrix-org/dendrite.git
cd dendrite
# For PostgreSQL setup, edit dendrite.yaml or use docker-compose
docker-compose -f build/docker/docker-compose.yml up
# Or build locally: go build -o dendrite ./cmd/dendrite

Daily commands: Build: go build -o dendrite ./cmd/dendrite. Run with PostgreSQL: ./dendrite --config dendrite.yaml (requires database config and federation certificates). For Docker: docker-compose -f build/docker/docker-compose.yml up. For P2P/WASM: cd build/dendritejs-pinecone && go run ..

• clientapi/clientapi.go — Main entry point for the client API component that handles HTTP routing and request dispatching for Matrix client endpoints.
• clientapi/routing/login.go — Core authentication and login handler; fundamental to understanding how Dendrite processes user authentication flows.
• appservice/appservice.go — Application service integration layer; essential for understanding how Dendrite bridges with external services and bots.
• .github/workflows/dendrite.yml — CI/CD pipeline definition; critical for understanding build, test, and deployment processes across the project.
• build/dendritejs-pinecone/main.go — Main monolith entry point for DendriteJS builds; shows how the application is bootstrapped and components are wired together.
• README.md — Project overview and maintenance status; clarifies that this fork is legacy and points to the maintained Element HQ repository.
• go.mod — Module dependencies and version constraints; essential for understanding external dependencies and required Go version.

• ClientAPI (Gorilla mux, Go http, clientapi/routing) — HTTP request routing and client-server API implementation; handles login, room operations, device management
  • Failure mode: Unable to serve client requests; users cannot login or interact with rooms
• Authentication Handler (bcrypt, JWT/tokens, clientapi/auth) — Credential verification, session token generation, user interactive authentication flows
  • Failure mode: Login failures; all client API requests require auth, so auth failure blocks all user access
• AppService Router (appservice package, event consumers) — Bridges external services (bots, bridges) into Matrix rooms; routes events and manages bridge identity
  • Failure mode: Bridge services disconnected; room events not relayed to external services

Add a New Client API Endpoint

1. Create a new routing handler in clientapi/routing/ (e.g., clientapi/routing/newfeature.go) that implements the HTTP handler following the existing pattern (clientapi/routing/newfeature.go)
2. Register the route in clientapi/clientapi.go by adding a call to router.HandleFunc() in the Setup() method (clientapi/clientapi.go)
3. Use clientapi/httputil/httputil.go helpers like JSONResponse() or ErrorResponse() for consistent response formatting (clientapi/httputil/httputil.go)
4. Add unit tests following the pattern in clientapi/admin_test.go or clientapi/clientapi_test.go (clientapi/admin_test.go)

Add a New Authentication Method

1. Define the new auth type in clientapi/auth/authtypes/ (e.g., clientapi/auth/authtypes/myauth.go) (clientapi/auth/authtypes/myauth.go)
2. Implement the verification logic in clientapi/auth/ (e.g., clientapi/auth/myauth.go) following the existing LoginMechanism pattern (clientapi/auth/myauth.go)
3. Integrate into clientapi/auth/login.go by adding a case to support the new auth type in login flow handlers (clientapi/auth/login.go)
4. Add tests in clientapi/auth/login_test.go or create clientapi/auth/myauth_test.go (clientapi/auth/login_test.go)

Integrate a New Application Service (Bridge)

1. Define appservice metadata structures in appservice/api/query.go for your bridge's requirements (appservice/api/query.go)
2. Add event handling in appservice/consumers/roomserver.go to route room events to your bridge (appservice/consumers/roomserver.go)
3. Implement bridge logic in appservice/appservice.go, extending the main component with bridge-specific message routing (appservice/appservice.go)
4. Add integration tests in appservice/appservice_test.go (appservice/appservice_test.go)

• Go — Memory-efficient, high concurrency support via goroutines, fast compilation, and static binary deployment ideal for a distributed homeserver
• PostgreSQL — Relational database chosen for strong ACID guarantees, transaction support, and efficient querying of Matrix state and event data
• Gorilla (mux/websocket) — Mature HTTP routing and WebSocket libraries providing the foundation for Matrix client-server and federation protocols
• Bleve — Full-text search indexing for room and message search capabilities without external Elasticsearch dependency
• Sentry — Error tracking and performance monitoring integration for production deployments

• Monolith architecture with optional component separation

  • Why: Simplifies deployment and development while allowing scalability through external components (roomserver, syncapi)
  • Consequence: Single binary deployment easier but harder to independently scale individual components; component separation requires careful API contracts

• In-process caching (ristretto) instead of Redis dependency

  • Why: Reduces external dependencies and operational complexity for small-to-medium deployments
  • Consequence: Cache not shared across multiple Dendrite instances; clustering requires careful coordination or external caching solution

• Support for Pinecone, Yggdrasil, and standard networking

  • Why: Enables decentralized deployments and privacy-focused networking alongside traditional Matrix federation
  • Consequence: Increased build complexity and multiple code paths; some features may not work across all network types

• Legacy maintenance status with redirect to Element HQ fork

  • Why: Resource constraints at Matrix.org Foundation; Element has resources for continued development
  • Consequence: This repository receives no updates; community should use element-hq/dendrite for active development

• Does not provide a managed SaaS offering; intended for self-hosted deployments
• Does not guarantee feature parity with Synapse; focused on core Matrix protocol compliance
• Does not support real-time database replication across WAN; expects local or LAN database access
• Does not include built-in load balancing; requires external reverse proxy for HA setups

Database requirement: Dendrite must connect to PostgreSQL or SQLite at startup; misconfigured dendrite.yaml causes immediate failure—check database credentials and schema migrations are applied. NATS broker: Multi-service deployments require NATS server running (nats-server/v2) or services will hang—see docker-compose.yml for reference config. Federation certificates: Requires TLS certs at paths specified in config (signing_key_path, server_key_path) or federation fails silently. Memory limits: SQLite mode is memory-intensive for large rooms; PostgreSQL required for production. Pinecone/Yggdrasil overlays: P2P modes require overlay network config; misconfiguration isolates nodes from federation. WASM builds: build/dendritejs-pinecone requires specific Go version and emscripten toolchain; failures are cryptic.

• Matrix Federation — Dendrite's core purpose is federated homeserver; understanding room state resolution, event signing, and server-to-server API is essential for any federation changes
• Event Sourcing & State Resolution — Dendrite stores immutable events and derives room state via deterministic resolution rules; critical for understanding consistency and handling forks in federation
• NATS Message Broker Pattern — Dendrite decouples services (roomserver, clientapi, federationapi) via NATS pub/sub; required to understand inter-service communication and deployment scaling
• Overlay Networks (Pinecone/Yggdrasil) — Dendrite can route via P2P overlays instead of DNS/TLS; essential for understanding mobile bindings and private network deployments in build/gobind-*
• Go Embedding & CGO Bindings (gobind) — build/gobind-pinecone exposes Dendrite as a library for mobile via Go's cgo and Android/iOS bindings; needed to contribute mobile features
• Database Schema Migrations — Dendrite supports both PostgreSQL and SQLite with versioned schema migrations in roomserver/storage/; breaking changes require careful migration logic to prevent data loss
• OpenTracing / Distributed Tracing — Dendrite integrates opentracing-go and jaeger for debugging complex federation flows; useful for performance profiling in multi-service deployments

• element-hq/dendrite — Official active fork where Dendrite is maintained after matrix-org sunset it in 2023; primary source for production builds and new features
• matrix-org/synapse — Original Matrix homeserver in Python; Dendrite is designed as a faster, more scalable alternative using the same sytest and complement test suites
• matrix-org/gomatrixserverlib — Core Matrix protocol library used by Dendrite for federation, room semantics, and event signing; must be synced for spec compliance
• matrix-org/complement — Language-agnostic test suite for Matrix homeservers including Dendrite; validates spec compliance via containerized client-server tests
• matrix-org/pinecone — P2P overlay network used by Dendrite for mobile and browser-based deployments via gobind and DendriteJS builds

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive integration tests for appservice query and consumer workflows

The appservice module (appservice/api/query.go, appservice/consumers/roomserver.go, appservice/query/query.go) lacks dedicated integration tests. Currently only appservice_test.go exists at the module level. Given that appservices are critical for Matrix interoperability, adding tests for query routing, consumer message handling, and error cases would improve reliability and catch regressions early.

• [ ] Create appservice/api/query_test.go with tests for appservice query endpoints (registration, user queries, room queries)
• [ ] Create appservice/consumers/roomserver_test.go with tests for event consumption and routing to registered appservices
• [ ] Create appservice/query/query_test.go with tests for query builder logic and parameter validation
• [ ] Add table-driven tests covering success cases, malformed requests, and appservice routing failures

Add GitHub Actions workflow for native dependency security scanning

The repo depends on numerous C/CGO bindings (matrix-org/go-sqlite3-js, mattn/go-sqlite3, yggdrasil-go) but lacks dedicated security scanning for native dependencies in CI. Currently dendrite.yml and other workflows focus on Go linting. Adding a workflow using tools like Snyk, Trivy, or cargo-audit (for Rust deps in Yggdrasil) would catch vulnerabilities in compiled dependencies before they reach production.

• [ ] Create .github/workflows/security-scan.yml with Trivy scanning for container images and Go binaries
• [ ] Add CGO dependency version pinning checks to detect outdated C library versions
• [ ] Integrate Snyk or similar for transitive dependency tracking of native packages
• [ ] Configure workflow to run on schedule and on PR changes to go.mod/go.sum

Add missing unit tests for clientapi/auth authentication flows

The clientapi/auth module (clientapi/auth/auth.go, clientapi/auth/authtypes/flow.go) is critical for user authentication but appears to have minimal test coverage based on the file structure. Only admin_test.go is visible at the clientapi level. Authentication logic should have comprehensive tests covering all Matrix auth flows (password, token, SSO, etc.) to prevent security regressions.

• [ ] Create clientapi/auth/auth_test.go with tests for session validation, credential verification, and token generation
• [ ] Create clientapi/auth/authtypes/flow_test.go with tests for auth flow state transitions and completion logic
• [ ] Add tests for edge cases: expired tokens, invalid credentials, concurrent auth attempts, CSRF protection
• [ ] Add tests for integration with the appservice module for external authentication providers

• Add comprehensive unit tests for appservice/query/query.go—currently only appservice_test.go exists but the query subpackage lacks test coverage for registration and event querying logic.
• Document the NATS message broker contract in a new docs/MESSAGING.md file with examples of service-to-service events (roomserver, federationapi, clientapi), as the consumer patterns in appservice/consumers/ are undocumented.
• Implement missing Matrix Client-Server spec endpoints by auditing clientapi/routing/ against spec version in use (check gomatrixserverlib version) and opening PRs for 3-5 unimplemented endpoints (e.g., certain admin APIs).

• High · Outdated Go Crypto Library — go.mod. The go.mod file shows 'golang.org/x/crypto v0.' which appears to be an incomplete or outdated version specification. This is a critical cryptographic library used for encryption, hashing, and other security operations. An incomplete version constraint could lead to using vulnerable versions. Fix: Pin golang.org/x/crypto to a specific recent stable version (e.g., v0.24.0 or later). Run 'go get -u golang.org/x/crypto' and ensure the full version is specified.
• High · Deprecated Docker Base Image — Dockerfile. The Dockerfile uses 'alpine:latest' in the final stage without a specific version tag. This creates non-reproducible builds and may include unpatched vulnerabilities. The base stage uses 'golang:1.22-alpine' which may be outdated depending on current date. Fix: Use specific Alpine version tags (e.g., 'alpine:3.19') and pin golang to specific patch versions (e.g., 'golang:1.22.5-alpine'). Implement regular vulnerability scanning.
• Medium · Missing Security Headers in Web Configuration — clientapi/routing/. No explicit security headers configuration is visible in the provided file structure. The codebase includes web routing components (clientapi/routing/) but no evidence of HSTS, CSP, or X-Frame-Options headers configuration. Fix: Implement comprehensive security headers in HTTP responses: X-Frame-Options, X-Content-Type-Options, Strict-Transport-Security, Content-Security-Policy, and X-XSS-Protection.
• Medium · Potential SQL Injection Risk in Database Layer — Various database-related packages (not fully visible in structure). The codebase appears to have SQL database interactions (dependencies include 'lib/pq' and 'mattn/go-sqlite3') but the provided file structure doesn't show clear parameterized query usage patterns in visible files. Database query construction patterns are not fully visible. Fix: Ensure all database queries use prepared statements and parameterized queries. Conduct thorough code review of all database access patterns. Use ORM libraries or query builders that enforce parameterization.
• Medium · Incomplete Dependency Version Specification — go.mod - golang.org/x/crypto and potentially others. Multiple dependencies in go.mod have unusual version specifications. Most critically, 'golang.org/x/crypto v0.' is incomplete. This could allow unexpected version selection and introduces supply chain risk. Fix: Complete all version specifications to exact versions. Run 'go mod tidy' and 'go mod verify'. Implement dependency scanning tools like Dependabot or Renovate.
• Medium · Missing Input Validation Visibility — clientapi/auth/. The authentication module (clientapi/auth/) handles user input but provided file structure doesn't show explicit input validation patterns for user registration, login, and interactive auth flows. Fix: Implement comprehensive input validation for all user-supplied data. Validate length, format, character sets, and content type. Use allowlists rather than denylists. Add rate limiting on authentication endpoints.
• Low · CGO Dependency in Cross-Platform Build — Dockerfile - build stage. The Dockerfile enables CGO_ENABLED=1 for native architecture builds but disables it for cross-architecture builds. This inconsistency could lead to different security properties and potential cgo-related vulnerabilities in native builds. Fix: Document the rationale for CGO usage. Consider disabling CGO entirely for security (no native C code execution). If CGO is required, ensure all C dependencies are from trusted sources and regularly updated.
• Low · No Visible Secret Management Configuration — Repository root - configuration files. No evidence of secret management (no .env.example, vault configuration, or secrets documentation visible). Dendrite handles sensitive data including user credentials, tokens, and keys. Fix: Implement proper secret management: use environment variables or external vaults (HashiCorp Vault, AWS Secrets Manager). Never commit secrets. Document secret management in CONTRIBUTING.md. Use .env.example with placeholder values.
• Low · Docker Image Contains Build Tools — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/matrix-org/dendrite shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live matrix-org/dendrite repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/matrix-org/dendrite.

What it runs against: a local clone of matrix-org/dendrite — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in matrix-org/dendrite | Confirms the artifact applies here, not a fork | | 2 | License is still Apache-2.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 562 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of matrix-org/dendrite. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/matrix-org/dendrite.git
#   cd dendrite
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of matrix-org/dendrite and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "matrix-org/dendrite(\\.git)?\\b" \\
  && ok "origin remote is matrix-org/dendrite" \\
  || miss "origin remote is not matrix-org/dendrite (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Apache-2\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Apache-2\\.0\"" package.json 2>/dev/null) \\
  && ok "license is Apache-2.0" \\
  || miss "license drift — was Apache-2.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "clientapi/clientapi.go" \\
  && ok "clientapi/clientapi.go" \\
  || miss "missing critical file: clientapi/clientapi.go"
test -f "clientapi/routing/login.go" \\
  && ok "clientapi/routing/login.go" \\
  || miss "missing critical file: clientapi/routing/login.go"
test -f "appservice/appservice.go" \\
  && ok "appservice/appservice.go" \\
  || miss "missing critical file: appservice/appservice.go"
test -f ".github/workflows/dendrite.yml" \\
  && ok ".github/workflows/dendrite.yml" \\
  || miss "missing critical file: .github/workflows/dendrite.yml"
test -f "build/dendritejs-pinecone/main.go" \\
  && ok "build/dendritejs-pinecone/main.go" \\
  || miss "missing critical file: build/dendritejs-pinecone/main.go"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 562 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~532d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/matrix-org/dendrite"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.