Standalone research report

Nostr Relay Stack — Final Ranking, Scoring, and Analysis

Final, role-aware scoring model for six relay-adjacent projects: nostr-rs-relay, strfry, Chorus, HAVEN, Citrine, and Ditto. The page preserves the full methodology, weighted criteria, composite scores, per-project breakdowns, role-specific interpretation, and inline source links.

Final scoring framework

All criteria are scored on a 0–100 scale and combined into a weighted composite out of 100. The weighting favors minimal attack surface, memory/runtime safety, self-hosting sovereignty, and role-correct architectural fit.

Criterion Weight Definition
C1. License & Anti-Capture 10% How strongly the license resists closed SaaS or black-box capture while remaining FOSS. Server-side copyleft is treated as structurally stronger than permissive licensing.
C2. Language & Runtime Safety 10% Memory-safety and runtime posture. Rust, Go, TypeScript/Deno, and Android/Kotlin stacks score differently from C++ in the presence of adversarial input and long-lived network exposure.
C3. Deployment & Self-Hosting 15% Single-binary friendliness, database footprint, packaging, small-hardware viability, and absence of forced cloud or SaaS dependencies.
C4. Privacy, Attack Surface & Synthetic Adjacency 20% How “dumb” and narrow the system remains. Cross-protocol bridges, complex policy engines, social UIs, cloud backups, and bundled services expand the surface and lower the score.
C5. NIP Coverage & Protocol Correctness 10% Breadth and seriousness of relay-relevant NIP support, with more credit given to dedicated relay implementations than to general application servers with secondary relay capability.
C6. Architecture Simplicity & Antifragility 15% Minimal moving parts, clear failure modes, clean database story, and avoidance of unnecessary bundling inside the relay core.
C7. Ecosystem Maturity & Maintenance Outlook 10% Observed adoption, packaging, documented operational maturity, release activity, and explicit roadmap or maintenance posture.
C8. Sovereign Alignment, Defaults & DR 10% How well the project’s defaults and structure fit personal, sovereign, or operator-controlled relay patterns, plus backup/disaster-recovery ergonomics where relevant.

Final composite ranking

The top of the field resolves into a tight backbone cluster, while the lower half remains materially useful but role-specialized.

Rank Project Composite Primary interpretation
1 nostr-rs-relay 90.3 Best overall backbone relay when memory-safety, clean architecture, and conservative relay-only design are prioritized.
2 strfry 88.1 Performance king for high-throughput public relays, with stronger copyleft but more risk due to C++ and a denser feature/policy surface.
3 Chorus 87.1 Best fit for personal, family, or small-community relay deployments where personal-relay defaults and moderation matter.
4 HAVEN 79.8 Integrated personal vault appliance with strong disaster-recovery semantics and multi-relay behavior, but materially more complex.
5 Citrine 76.5 Mobile adjunct relay living on Android; useful as a pocket outbox/inbox or experimental node, not as backbone infrastructure.
6 Ditto 71.0 Nostr-native social server and Mastodon-compatible application layer; strong in its niche, but not a minimal sovereign relay substrate.
Backbone cluster
90.3 / 88.1 / 87.1
nostr-rs-relay, strfry, and Chorus remain tightly grouped at the top.
Best personal relay bias
Chorus
Documented personal-relay mode, management API, behavior docs, and OpenSats-backed development.
Best integrated vault semantics
HAVEN
Four logical relays, embedded Blossom, JSONL backup/restore, and periodic backup flows.

Backbone relay tier

This tier covers the dedicated relay implementations that most cleanly map to “core infra” rather than “appliance” or “application server” roles.

nostr-rs-relay — 90.3 / 100

Final #1 overall

Rust relay with SQLite by default and experimental PostgreSQL support, mirrored from SourceHut to GitHub. The official README describes it as a relay written in Rust that “supports the entire relay protocol” and persists data with SQLite.

Repository / README Config example Issues / current surface
Criterion Score Notes
C1. License & Anti-Capture 80 MIT license keeps the code maximally reusable but does not impose a server-side copyleft barrier on closed forks or hosted derivatives.
C2. Language & Runtime Safety 95 Rust places it in the strongest memory-safety class in this comparison.
C3. Deployment & Self-Hosting 93 Single-binary relay with SQLite by default, optional PostgreSQL, and clear configuration exposure through the sample config.
C4. Privacy, Attack Surface & Synthetic Adjacency 90 Relay-only posture, no bundled social UI, no Fediverse bridge, and no integrated cloud/backup platform logic inside the core.
C5. NIP Coverage & Protocol Correctness 90 Positioned as a serious production relay rather than a client-adjacent utility. Practical coverage is strong even where every current or emerging NIP is not present.
C6. Architecture Simplicity & Antifragility 90 Rust + SQLite is a clean stack with legible failure modes and modest operational overhead.
C7. Ecosystem Maturity & Maintenance Outlook 93 One of the de facto standard relays, long-lived, mirrored from SourceHut, and still active enough to show open issues and recent compatibility work.
C8. Sovereign Alignment, Defaults & DR 90 Excellent fit as general sovereign relay infrastructure. Backup and recovery are generic and straightforward through SQLite snapshots and filesystem tooling rather than bespoke appliance logic.
Role conclusion: Best overall choice for general-purpose sovereign relay infrastructure when memory-safety, conservative architecture, and a relay-only design are weighted more heavily than raw performance maximalism.

strfry — 88.1 / 100

Backbone performance king

High-performance relay in C++ using LMDB. The official repository positions it as a relay for the Nostr protocol, with dedicated deployment documentation, a router/replication document, and an active changelog reflecting advanced features such as negentropy-related work.

Repository / README Deployment guide Router / replication docs Changelog
Criterion Score Notes
C1. License & Anti-Capture 90 GPL-3.0 gives it a stronger anti-capture posture than the MIT-licensed backbone competitors.
C2. Language & Runtime Safety 65 C++ and LMDB can be extremely fast, but the language/runtime posture is materially riskier than Rust or Go in a hostile network environment.
C3. Deployment & Self-Hosting 95 Single binary, no external database, operator-friendly deployment docs, and production-oriented features such as hot reloads and zero-downtime restarts.
C4. Privacy, Attack Surface & Synthetic Adjacency 88 Core remains relay-centric, but policy/plugin paths and broader feature density create additional code paths compared with a more conservative relay.
C5. NIP Coverage & Protocol Correctness 93 Feature-rich and widely used on serious relays. Changelog and docs reflect a broader advanced-relay feature surface than many competitors.
C6. Architecture Simplicity & Antifragility 85 Operationally elegant as a single binary, but more tuned and denser than the boring-relay baseline represented by nostr-rs-relay.
C7. Ecosystem Maturity & Maintenance Outlook 95 One of the most visible high-traffic relay implementations in the field, with a mature operator ecosystem around it.
C8. Sovereign Alignment, Defaults & DR 92 Strong fit for public or community relay backbones. LMDB snapshots are straightforward, and operator policy hooks support deliberate edge control.
Role conclusion: Strongest candidate for high-throughput public or community relays where raw performance and advanced relay features justify accepting the tradeoff of a memory-unsafe language and a somewhat denser feature surface.

Chorus — 87.1 / 100

Personal/community relay specialist

Rust relay with first-class documentation for deployment, configuration, behavior, management, and personal relay mode. The official README states that it can work as a personal relay or an open relay, can serve as a Blossom server, and includes management tooling.

Repository / README Personal relay docs Behavior docs OpenSats LTS
Criterion Score Notes
C1. License & Anti-Capture 80 MIT license keeps the relay open and forkable, but offers weaker anti-SaaS resistance than GPL/AGPL choices.
C2. Language & Runtime Safety 95 Rust gives Chorus the same top safety class as nostr-rs-relay.
C3. Deployment & Self-Hosting 88 Single-binary deployment remains strong, though the broader feature set and management surfaces increase configuration depth.
C4. Privacy, Attack Surface & Synthetic Adjacency 85 Still firmly Nostr-native, but built-in moderation, IP-level controls, management APIs, and optional Blossom widen the surface relative to a pure dumb relay.
C5. NIP Coverage & Protocol Correctness 90 Particularly strong for personal/community use-cases through documented support for AUTH and adjacent relay features described in the README and docs.
C6. Architecture Simplicity & Antifragility 82 Slightly more “smart relay” than the relay-only baseline, but far simpler than a bundled social platform.
C7. Ecosystem Maturity & Maintenance Outlook 88 Active development plus explicit long-term support via the OpenSats LTS grant materially improve outlook.
C8. Sovereign Alignment, Defaults & DR 93 One of the strongest fits for operator-controlled personal or small-community relay topologies due to explicit personal relay mode and well-explained behavior defaults.
Role conclusion: Best fit for personal, family, or small-community relay deployments where the goal is not merely “a fast relay” but a documented personal-relay environment with operator control, moderation, and Rust safety.

Vault / appliance tier

This tier covers systems that are more than a dumb relay: they package operator logic, multi-role behavior, or backup semantics directly into the application.

HAVEN — 79.8 / 100

Integrated personal vault appliance

Go-based “High Availability Vault for Events on Nostr.” The official README explicitly describes it as “the most sovereign personal relay” for storing and backing up sensitive notes such as eCash, private chats, and drafts. It also advertises four logical relays (Private, Chat, Inbox, Outbox), an embedded Blossom media server, web-of-trust, whitelisting/blacklisting, JSONL backup/restore, periodic cloud backups, blastr, and note import.

Repository / README Full README Releases Release verification
Criterion Score Notes
C1. License & Anti-Capture 80 MIT license keeps the project fully open but does not impose server-side copyleft.
C2. Language & Runtime Safety 90 Go places HAVEN in a materially safer runtime class than C++, though not as strict as Rust.
C3. Deployment & Self-Hosting 90 Deliberately appliance-like: prebuilt binaries, wrappers, verification docs, and a broad set of packaged deployment paths.
C4. Privacy, Attack Surface & Synthetic Adjacency 70 The same features that make HAVEN powerful—four relay roles, embedded Blossom, WOT, blastr, import flows, and periodic cloud backup paths—also expand the attack surface substantially.
C5. NIP Coverage & Protocol Correctness 75 Optimized for personal vault behavior rather than broad generic-public-relay parity. Correct for its role, but not the strongest as a universal relay.
C6. Architecture Simplicity & Antifragility 75 Intentionally “not so dumb.” The appliance quality is valuable, but complexity rises accordingly.
C7. Ecosystem Maturity & Maintenance Outlook 80 Well-documented and packaged, with visible releases. At the same time, the project presents itself as feature-complete and focused on fixes rather than open-ended expansion.
C8. Sovereign Alignment, Defaults & DR 85 Very strong vault semantics through JSONL backup/restore and personal multi-relay behavior. It is strongest when treated as a personal appliance rather than as a generic backbone relay.
Role conclusion: Excellent one-box personal vault for notes, media, inbox/outbox, and backup-heavy use-cases. The power comes from bundling; the main cost is complexity and a wider operational surface.

Mobile adjunct tier

This tier addresses mobile-first or mobile-embedded relay behavior rather than classic server infrastructure.

Citrine — 76.5 / 100

Relay in the phone

Android Nostr relay. The official repository says it “allows any nostr client that supports Android to send and receive events from this application.” The documented feature set includes database export/import, export-only-my-events, relay management controls, broadcast-after-online behavior, and content resolvers. The project is also listed on F-Droid.

Repository / README F-Droid package Feature list
Criterion Score Notes
C1. License & Anti-Capture 80 MIT license, straightforward and permissive.
C2. Language & Runtime Safety 90 Kotlin/Android app stack is memory-safe at the language level, though the broader mobile environment is not minimal or operator-controlled in the same way as a dedicated server.
C3. Deployment & Self-Hosting 80 Very easy to deploy for Android users, but still structurally tied to a smartphone rather than a normal relay host.
C4. Privacy, Attack Surface & Synthetic Adjacency 75 The app itself is fairly simple. The bigger issue is the Android substrate: vendor layers, battery policies, and a non-minimal mobile environment.
C5. NIP Coverage & Protocol Correctness 65 Feature coverage is aligned with “relay in the pocket,” not with the expectations placed on a backbone or public relay implementation.
C6. Architecture Simplicity & Antifragility 70 The code path is conceptually simple, but a phone remains a comparatively fragile runtime for always-on infrastructure.
C7. Ecosystem Maturity & Maintenance Outlook 80 Public package listing and continued source availability keep it credible as an actively distributed project.
C8. Sovereign Alignment, Defaults & DR 75 Database export/import and “export only events from your account” are meaningful for personal portability, but the Android environment limits its suitability as core infrastructure.
Role conclusion: Best interpreted as a traveling relay, personal adjunct, or experimentation node rather than as a foundation for relay backbones or shared community infrastructure.

App-server / social stack tier

This tier covers systems whose real center of gravity is application-layer community or social functionality rather than minimal relay substrate.

Ditto — 71.0 / 100

Nostr social server / Mastodon-compatible surface

Ditto is described in the official repository as “a Nostr server for building resilient communities online.” It is AGPL-3.0 licensed, built in TypeScript for Deno, and paired with dedicated documentation. The surrounding Soapbox material frames Ditto as a way to create a customizable social network that is decentralized and free from ads and tracking, while also unlocking Mastodon app compatibility.

Repository / README Docs Mastodon app bridge article Changelog
Criterion Score Notes
C1. License & Anti-Capture 95 AGPL-3.0 is the strongest anti-SaaS / anti-black-box license posture in this comparison.
C2. Language & Runtime Safety 90 TypeScript on Deno is memory-safe at the language/runtime layer and benefits from a modern platform toolchain.
C3. Deployment & Self-Hosting 75 More complex than a relay binary: the documented installation flow involves Deno, PostgreSQL, and surrounding service infrastructure.
C4. Privacy, Attack Surface & Synthetic Adjacency 55 Application server by design: web surface, social features, compatibility layers, and broader protocol adjacency create the widest attack surface in the field.
C5. NIP Coverage & Protocol Correctness 70 Strong enough to serve its own intended community layer, but relay correctness is not the sole center of gravity the way it is for the dedicated relay projects.
C6. Architecture Simplicity & Antifragility 60 Architecturally heavy compared with the dedicated relays; the complexity is a feature of the design, not an accident.
C7. Ecosystem Maturity & Maintenance Outlook 82 Active enough to maintain docs, changelogs, and a continuing Soapbox ecosystem around it.
C8. Sovereign Alignment, Defaults & DR 60 Useful for self-hosted communities, but still closer in spirit to a social platform than to a minimal sovereign relay substrate. Disaster recovery follows normal app-and-database procedures rather than relay-appliance semantics.
Role conclusion: Strong option for a Nostr-native social/community layer, but the wrong abstraction layer for anyone seeking the cleanest possible relay backbone.

Role-based final summary

Backbone / high-traffic & general relays

  • nostr-rs-relay — best overall for memory-safe, conservative, relay-only deployments.
  • strfry — strongest when raw throughput and advanced relay features outweigh the downside of a C++ core.
  • Chorus — close to the top cluster, especially where personal/community control matters more than public-relay extremal performance.

Personal / family / operator-controlled relay patterns

  • Chorus — best documented personal-relay posture.
  • HAVEN — strongest one-box vault/appliance semantics.
  • Citrine — mobile adjunct, not infrastructure core.

Integrated vault / appliance logic

  • HAVEN dominates this slice by embedding four relay roles, backup flows, and a Blossom server directly into the application.

Social / community application layer

  • Ditto belongs here rather than in the backbone bucket. Its value comes from being a social/community server, not from being the leanest relay substrate.

Final interpretation: the field resolves into a top relay cluster (nostr-rs-relay, strfry, Chorus) and three specialized systems (HAVEN, Citrine, Ditto) whose value depends heavily on role correctness rather than direct backbone comparability.

Standalone HTML/CSS reference page with embedded styling and inline links to project repositories, docs, changelogs, install material, and supporting sources.