satoshiplanet

, an open-source Nostr relay written in Rust. I wanted to introduce the project properly instead of just dropping a link.

The starting question was simple: how much can one relay do with 

 without compromising on spec coverage? The current answer is 36+ relay-side NIPs, a Blossom file server, a read-only REST API and NIP-86 management — all in a single static binary. I chose Rust because I wanted no runtime dependencies, a small memory footprint, and predictable behaviour under load.

A few things that might matter to relay operators:

curl -fsSL https://raw.githubusercontent.com/iqbqioza/nostrfy/main/install.sh | sh

This is still v0.1.x, and I'm actively working on it. I won't pretend it's battle-tested at the scale of the largest relays, but it's running the project relay and has been tested on small VPSes. What would help most right now is feedback from relay operators and client devs: what would make you switch, what's missing, or what breaks when you point a client at it? Happy to answer anything here.

nostr

devs

Hi Stackers,

I'm the developer behind [nostrfy](https://nostrfy.org), an open-source Nostr relay written in Rust. I wanted to introduce the project properly instead of just dropping a link.

The starting question was simple: how much can one relay do with **one binary and one config file** without compromising on spec coverage? The current answer is 36+ relay-side NIPs, a Blossom file server, a read-only REST API and NIP-86 management — all in a single static binary. I chose Rust because I wanted no runtime dependencies, a small memory footprint, and predictable behaviour under load.

A few things that might matter to relay operators:

* **Spec coverage:** every relay-side NIP I could find, including NIP-50 search, groups, media, zaps and NIP-86. NIP-11 advertises only the NIPs that are actually enabled.
* **Small footprint:** comfortable on a 0.25 vCPU / 512 MB VPS. LMDB via heed; the memory map is a sparse reservation, so RSS stays flat as the database grows. Pre-built binaries for Linux x86\_64/aarch64 and FreeBSD x86\_64.
* **Under load:** dedicated reader threads for WebSocket and REST, a single batched LMDB writer. On an 8-thread laptop with a fresh database: \~21k events/sec ingest on one connection, 10,000/10,000 fan-out, a 20k-event query in 0.32s, NIP-50 search over 10k results in 0.26s, and 7.9 MB private RSS with a 252 MB database.
* **Ops included:** `nostrfy init`, `check`, `start` (daemon), `stats`, `upgrade`, log rotation and SIGHUP reload.
* **No rebuild to change settings:** limits, NIP toggles and storage all live in `nostrfy.toml`.
* **Migration:** one command to import an existing strfry database — offline, verified and safe to re-run.

Install:

```sh
curl -fsSL https://raw.githubusercontent.com/iqbqioza/nostrfy/main/install.sh | sh
```

Then `nostrfy init && nostrfy start`.

* Live relay: `wss://relay.nostrfy.org`
* Source: [https://github.com/iqbqioza/nostrfy](https://github.com/iqbqioza/nostrfy)
* Docs: [https://nostrfy.org/docs/](https://nostrfy.org/docs/)
* Benchmarks and methodology: [https://nostrfy.org/docs/operation/#throughput](https://nostrfy.org/docs/operation/#throughput)
* License: MIT OR Apache-2.0

This is still v0.1.x, and I'm actively working on it. I won't pretend it's battle-tested at the scale of the largest relays, but it's running the project relay and has been tested on small VPSes. What would help most right now is feedback from relay operators and client devs: what would make you switch, what's missing, or what breaks when you point a client at it? Happy to answer anything here.