The Rise of Paid Nostr Relays
Adding Bitcoin monetization capabilities to Nostream relay through the ZBD API
Unless you’ve been living under a rock for the past few months, you have heard of the up-and-coming revolutionary and possibly-decentralized data protocol called Nostr. Nostr is a generic communications protocol that has a myriad of potential applications, but the current hot topic is social media — aka Twitter replacement. Look no further than Snort, Damus or Amethyst if you want to get going joining Nostr.
If 1 week in BitcoinDev-land feels like 2 years, then 1 week in NostrDev-land is at least a full decade. The sheer number of new client apps, advanced relay implementations, and developers getting their hands dirty with Nostr is simply staggering. The ecosystem is growing so fast that there is already a Nostr Conference schedule for March called Nostrica.
Developer-interest metrics can be notoriously bad at identifying patterns and trends. BUT, if we are to take into account the recent wave of interest into the Nostr protocol simply by looking at the number of GitHub stars on the repository - WOW!
Now you may be thinking that this is probably akin to the growth of other open source protocols that have received similar adoption. And you would be right to think that. But the difference is actually pretty stark when you compare Nostr’s growth with other protocols of similar kinds. Below you see the chart comparisons for Nostr, bitcoin, IPFS, and LND GitHub stars. While it’s clearly really early days for the Nostr protocol, its growth thus far has been nothing short of incredible.
Network Growth
As the Nostr network continues to grow, and software solutions for both clients and relays continue to mature, one of the big discussion topics that comes up time and time again is monetization business models.
Most of the cost of running the Nostr network is on its distributed relay infrastructure. Relays must handle the storage of events, the compute cycles that allow for clients to connect, send, and fetch events, as well as the necessary bandwidth used to relay these events to tens of thousands of users. Currently all of the Nostr relays are being run by enthusiasts — folks that are paying out of their pockets to provide infrastructure for clients to connect and post to.
No one is earning any real return from running Nostr relays in production at the moment, and this must change for the continued growth of the network.
For the network to mature, there must be incentive structures in place that ensure relay operators are incentivized to provide always-online infrastructure to users. Any decently mature distributed network will also have to deal with much more adversarial conditions around spamming and denial-of-service attacks.
While Nostr is itself a lightweight protocol, scaling relays to tens of millions of users will be very costly. Therefore it is imperative that we arrive at monetization schemes for Nostr relay operators to earn returns on their server infrastructure provisioning.
Fee Monetization
While it’s all fun and games to theorize about monetization techniques for Nostr relays, when it comes to actually building these on relay implementations it’s a different beast altogether.
It is important to understand that this is NEW. No one has successfully monetized a Nostr relay, so any and all attempts right now are nothing more than that — attempts. There will be models that work and models that don’t. Ultimately we must start somewhere.
Bitcoin is how Nostr will be monetized.
Bitcoin is the perfect fit for the money layer of the Nostr network. Apart from the obvious reasons around its decentralized nature, censorship-resistant capabilities, and global adoption reach, Bitcoin fits into Nostr because of the Lightning Network. By relying on Lightning Network payment requests we are able to achieve a money layer that provides cheap and instantaneously-settled value transfer.
There are various ways for a relay operator to charge for the work their relay is doing on behalf of its clients. Specifically I believe there are 3 distinct types of fees that operators could begin entertaining in order to make their relays more sustainable from a cost perspective, and more stable from a DDoS and spam-protection perspective.
Storage (pay per size)
The entirety of the Nostr protocol surrounds a generic event object that contains 7 simple parameters. All actions inside of Nostr are events. If you’re making a post to your feed — that’s an event. If you’re editing your profile metadata — that’s an event. If you’re liking a post on your favorite app — that’s an event.
All of these events are sent by clients to relays, and relays have to store that data in order for other clients to fetch it at a later date/time. It then becomes clear that the more events a relay has, the larger their storage needs are. And with the current growth of the network the expectation is that there will only ever be more users, making even more events.
What if relay operators could charge users/clients based on how much data they store on their behalf? Maybe the path forward is to charge X satoshis per every Y MB of event data that is stored on a user’s behalf?
Publication (pay per event)
If we know that everything in Nostr is an event, and that in order to interact with anyone in the network one must publish events, why shouldn’t relay operators simply charge users per event? The proverbial `pay-for-what-you-use` is another model that could be tried by relay operators. The more the user does with this relay, the more it would cost for them.
The biggest challenge for this pay-per-event model to work is FRICTION! Microtransactions are a burden to users if they are not kept out of sight, and interrupt the user experience at every engagement. Users will simply churn out and not return.
I still have a lot of hope that this is a model that will be attempted, but it does feel a bit early for it to work at scale, in an interoperable manner across all client apps and relays.
Admission (pay per pubkey)
KISS = Keep It Simple Stupid
Maybe we should start small, simple, and iterate from there. A straightforward monetization mechanism could be to have a simple allowlist that includes all of the public keys / users that have paid an admission fee set by the relay operator.
The relay operator will then be able to monetize that service with an upfront fee for providing it to users. Additionally, operators are given the ability to further decide to remove users / public keys from the allowlist if they breach any of the Terms of Service they stipulated. Users not in the allowlist will have their relay connections dropped, and no further posting or fetching of events is available for that public key. This mechanism also allows operators to deter spammers, and provides for a more stable Nostr data experience when compared to public free relays.
While it remains to be seen how operators will handle actively monitoring their users and events, it is quickly becoming clear that running a large scale Nostr relay is not a small task, and requires active maintenance resources.
Enter Nostream + ZBD
Nostream is one of the most feature-rich Nostr relay implementations out there. It is written in TypeScript, authored and maintained by Ricardo Arturo - a prolific developer and Core Nostr Contributor. This relay implementation has got support for the most used NIPs, fully configurable rate limiting settings, blocklisting and allowlisting of pubkeys and event keys, and much much more.
On the latest version of Nostream, a relay operator is able to connect a ZBD API key to their relay, and with 2 simple configuration settings activate paid access support.
From that moment on, that relay is effectively monetized through the Lightning Network and payments can be performed by any user from anywhere in the world.
When initiating your Nostream relay, with a simple set of configuration parameters and a ZBD API key, anyone is now able to directly monetize the storage, compute, and bandwidth costs of running a Nostr relay!
How it all works!
When a user visits the homepage of the paid Nostream relay, they are shown the one-time admission fee requirement screen. The user is also provided a detailed Terms of Service that relay operators can choose to modify to their own desires.
The payment orchestration flow is done through Bitcoin Lightning Network, so when a user clicks pay 1000 sats, a Lightning invoice is created and displayed as a QR code. This payment request is payable by any Lightning-enabled Bitcoin wallet in the market.
Here I’m using the ZBD Browser Extension for Google Chrome to make the payment directly from my browser with 1 click.
Once the payment is complete, the user’s public key is then added to that relay’s allowlist. From then on, that user is able to successfully connect to the relay. They can now post and fetch events as much as they want.
Ricardo runs a paid Nostream relay instance at eden.nostr.land if you’d like to try the payment flow yourself.
To make the entire flow even simpler, Ricardo was able to configure each Nostream relay to have its own identity inside of Nostr (public key). Which means that the same information that is shown in the website’s UI is also sent to the user as a private DM message. If their application handles paying directly with a wallet (like Snort does below), the payment flow can be even smoother.
Once the payment settles, the relay also sends a message stating that their public key has been added to the list of admitted users.
Even with just this initial implementation of a paid relay by admission fee, we have already identified a few paths worth exploring further:
Creation of a set of separate NIPs that define events for a relay to send payment requests directly to clients, and have that UI/UX be handled differently than just a DM message.
Creation of subscription services such that relays are able to automatically let users/pubkeys know their access is going to be terminated unless payment is completed within X days.
Given the recent surge of new users to Nostr, one theme has been clear: free relays are melting under the increased demand, while paid relays are providing the most reliable services.
Both nostr.milou.lol and Ricardo’s eden.nostr.land are currently running Nostream with paid relays configuration. And more are popping up everyday! If you are seeking a more stable experience for sending and fetching events in Nostr, give a paid relay a try!
ZEBEDEE is the easiest way to monetize your Nostr relay today!
Use Bitcoin Lightning Network with the ZBD API and start earning revenue for providing distributed infrastructure to the open Nostr network!
Focus on providing the best Nostr relay infrastructure for your users, and let ZBD focus on what we do best — Bitcoin Lightning Network APIs and infrastructure provisioning.
If you’re trying to run a paid Nostream relay, get in touch with me on Twitter @andreneves or DM me on Nostr and I’ll get you onboarded with an invite code.
ZBD provides the most in depth array of Lightning Network API protocol support ranging from Lightning invoices (BOLT11 payment requests), to LNURLs, to Lightning Addresses, and even Keysend (spontaneous payments). We’re here to support you and your teams on your journey to introduce real value to user experiences!
If you’re building on Bitcoin and Lightning Network, it must be on ZBD.
Hopefully the next post will be on running a fault-tolerant high-availability Nostr relay. Yes, enterprise nodes are already here!
- AN
Yessssss! Finally it's here. Such a needed thing to incentivise larger relays to run, but also to show how lightning is the perfect fit as the payment layer.
A couple thoughts as I read this.
1. What are your thoughts on using LSAT since it's tied into the 402 http status code? Then you can pass those credentials around to other people while the relay keeps track of the remaining credits. I can then share it with my family or resell on a secondary (nostr based) market.
2. With a bunch of these web clients coming out for Nostr would you reconsider webln as a way for them to interact with ZBDs extension like you had before?
Awesome article even more awesome developments. Looking forward to the next!
I've got my NOSTREAM relay up and running and would like to enable pay-per-relay. While this post gives a general sense of how to set it up. I can't seem to find a detailed set of instructions especially the zebedee side of things. Registered for an API key but that seems stuck waiting on approval.
Can you provide a links to specific docs? Thanks for all the hard work on this. Anxious to try it out.