How do relays work, anyway?
Relays form the foundation of Nostr. At their core, they are a database of Nostr events.
There can be many types of relays, such as personal relays, archival relays, paid relays, and so on. These all use different types of software.
Most relays are small relays, designed to cater to a small set of people. These could be small communities, WoT relays, or personal relays. These relays often use software that stores data on a single server, such as:
- Haven
- nostr-rs-relay
- Aegis
The flaw with these is that the server is a single point of failure.
This usually does not matter, as these relays are usually used alongside other relays. But for large relays, this is not acceptable.
Going redundant
There are also relays that can operate with multiple servers, such as strfry or Immortal.
These are focused on larger relays, being more optimized for performance. These can also tolerate servers going offline, as the relay database is copied to multiple servers at once.
These power many large relays today. These used to power Nostr.land, but we have switched away from them due to multiple issues.
Why build your own?
It is easy to operate these relay implementations, if you constrain yourself to a small box.
Most relay implementations provide little flexibility. Usually, they assume that you will only have one big database, and only basic access control. (whitelists)
Advanced features, like caching a relay is not possible: You have to create a full copy of the relay for each server. Eventually, regional mirrors will be multiples of times more expensive than the actual relay.
Nostream
We have operated Nostream at scale very early on in 2023. It used a significant amount of resources due to an inefficient query engine. This led to even the largest servers getting saturated.
We also were limited to a simple pay-for-access scheme, and Nostr.land, as it is toda,y would not be possible. So, we switched to strfry.
strfry
strfry is a great piece of software. This has been what we have used up until now, and had served us well. It works for most paid relays and small relays.
But when we planned to introduce an aggregator, the issues started becoming more obvious to us.
Every so often, there is a breaking change to the database format. Each time this happens, we have to take the relay down, export all events, and reimport them. We had to do a similar process to compact the database.
Upgrades and compaction were slow, and had to happen for each relay server. This is caused primarily by the fact that strfry requires each server to keep a full copy of the database, which also made it more expensive to operate.
strfry also had no good extensibility story; the only provided interfaces were a way to filter writes. There was no way to add NIP-42 authentication, or pay-to-read, and other features like our unified connection architecture without needing a proxy layer.
In the end, strfry took more than two times the server resources compared to the current NFDB implementation, while actively slowing down development.
NFDB: Our in-house relay software
A few months ago, we began work on NFDB. It is a distributed relay which can run on multiple servers. It consists of several components:
- The frontend, which receives requests from users, and routes them
- The NFDB service, which executes queries and modifies the database
- The SmartCache service, which can cache frequently accessed data on the edge
- A reliable distributed database to actually store the data
Each component runs independently and is redundantly deployed.
This allows us to both be more resilient to failures, and allows us to add more capacity as needed.
We have also implemented many features that we need into the database directly.
One example is Unified Connections, which allows us to deliver the functionality of multiple relays in one connection. This both saves mobile data and reduces issues with Nostr clients.
Over the last month, with NFDB we have been able to:
- Serve over 634 million requests with zero issues
- Store over 350 gigabytes of events
- Reduce operational costs by over 2x
- Ship features such as the aggregator and inbox
- Provide a consistent and good experience to users
Currently, we are working on a new revision (NFDB 2.1) that includes a multitude of improvements, including a rewrite of a core component in Rust.
This decision has been influenced primarily by the impedance mismatch between Go's stackful coroutines for concurrency, and the database library's API.
SmartCache: Caching without the hassle
Many relay software do not support caching relays, only a full replica of a relay.
SmartCache is a new addition to NFDB that is coming over the coming weeks, which allows many commonly accessed events, such as your home feed, to load faster from a local server.
This will allow us to cache the nostr.land relay including the aggregator in multiple regions, which will improve feed loading times significantly.
Search
Search is coming to NFDB relays over the coming months, as we are in the process of finalizing more important features.
This will be available on both nostr.land and aggr.nostr.land in any client that supports NIP-50.
Hosting your relay with NFDB
Currently, NFDB is only available for nostr.land. But if you are interested in being able to host your own relay with one click, drop a reply, or DM us.
We are currently working with several customers to see the viability of such a relay.
The Other Stuff
- Unified Connections is coming to the aggregator soon, along with a new configuration panel. Speaking about that,
- Project Monad is coming soon. No comment :)
- A newer and more efficient spam filter will be deployed to the aggregator. This will also improve the visibility of new users.
If you have any questions, drop them down below in the replies.