Nostr, a growing hub for the Bitcoin community, faces some incentives challenges if it’s going to reach significant scale.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and tech-oriented Bitcoin podcast host.
I’ve written an article on the basics of what Nostr is and what “events” are and how they work, as well as one on some of the key management issues that the platform is going to have to solve. Now, let’s go through some of the issues that relay servers are going to have to address going forward in the long term.
The entire Nostr protocol depends on people somewhere running a relay server. There is no “Nostr network,” there are only relays and clients that connect to relays. There need to be incentives for people to run relays, and in the long run, that is ultimately going to be a huge part of how far relays can scale. There will never be Nostr relays at the same scale as Twitter servers unless they can be operated profitably or, at the very least, bring in enough money to pay for the costs of running themselves.
Advertising
Advertising would be very trivial to completely block, making it a non-viable solution, given how Nostr works as a protocol. A relay server could try and use advertising as a revenue model, it’s obviously the dominant revenue model for pretty much every free service there is online, but the problem with that is that users would essentially have to opt into it. Relays could easily just inject advertisements into the events that they send to clients, but clients could also just easily filter those out of the user interface if the advertisement events were not created by a public key they have intentionally subscribed to.
Even if a relay operator produced a client that did not do that, there is no way to stop users from utilizing other clients that did from fetching data from their relay. They wouldn’t even really know whether someone’s client was hiding ads from the users or not, and because of that lack of insight, this model is pretty much dead on arrival unless users intentionally opted into it. And even then, the relay operator wouldn’t have a sound basis to show anything about the level of engagement to advertisers.
Micropayments
Micropayments is another obvious solution, especially given the current attempts to integrate Lightning more tightly into Nostr applications. This model would offer a lot of flexibility in terms of how to charge. Relays could charge for just posting events there, they could charge for downloading events to read, they could do a combination of both and adjust the price of each one depending on how much of their resources were consumed by one or the other. I’m kind of skeptical personally, though, that this model could scale to the size of something like Twitter. Content micropayments are showing themselves viable in many niche things built on Lightning, but there are two fundamental problems with that really scaling to a global size.
First, there just isn’t enough Bitcoin adoption currently for that. Even if everyone would magically become okay with paying for every little service interaction over Nostr, there aren’t enough people holding bitcoin to support it at such a massive scale as Twitter. Relays could charge subscriptions through fiat, but those payment rails aren’t going to support a fraction of a cent payment for each posted or downloaded event. Secondly, people have literally grown up used to services like this being free. It’s just what people expect. Micropayments alone I don’t think will really cut it to support relays at huge scale either.
There could be a way to make micropayments “stickier” or more sustainable without imposing them on literally every class of user utilizing your relay. There has been a lot of discussion of building all kinds of applications on top of Nostr besides a Twitter clone: GitHub, Wikipedia, even decentralized gig-worker apps like Uber. That last one is the key here. Something like Twitter or Google is just a service that people have gone their entire lives taking for granted as being free. Economic trade is not a place where those assumptions are deeply ingrained in them. People are very accustomed to paying a fee to post a job advertisement somewhere, or paying a cut to a marketplace operator when they order something online. They just assume and expect it from the outset. This could offer relays a way to create a reliable backbone of income from their users without creating a large amount of friction or breaking the expectations of the average potential user.
If micropayments are going to be a factor as well, then the relay operator is going to have to run a Lightning node in order to receive funds from users in the first place. This could potentially amplify that revenue if properly synergized with whatever micropayment model a relay implemented. The bigger a relay server is in terms of the revenue it’s drawing in, the more liquidity it’s going to need on the Lightning Network to facilitate that. If operators properly plan how they deploy or allocate that liquidity across the network, then simply the act of running a routing node could potentially be a not-insignificant revenue stream in its own right in addition to whatever they charge to accept or deliver data through their relay.
Can Nostr Scale Relays?
Even gluing all of these together though, can these different revenue models support a Twitter-scale relay? Maybe a gig-work relay could, but wouldn’t its rational move be to specialize in only those types of events? What about other use cases, like social media? Maybe an individual relay operating at that scale for certain use cases of Nostr will just not be economically viable. The basic structure of the protocol was done in a very simple way so that it can’t be easily censored or have its events contents tampered with in a non-evident way. That structure comes with overhead, though.
That doesn’t fundamentally break Nostr at all if it winds up being true. After all, clients can connect to whatever relays they want. Clients aren’t married to any individual relay, they can grab events from dozens of relays at a time. Events stored at one relay can even point to events stored at totally different relays. The protocol can still work for any use case in practice, even if individual relay servers have hard limits that they can’t scale beyond in terms of user counts or the number of events they are storing and serving.
However… this dynamic does raise issues itself in how to index and track all that data scattered all over different servers. Do you have a complete view of a series of events referencing each other? Is something missing?
A distributed web of smaller relays will run into scaling challenges just as a single relay trying to be massive will. But I’ll save that one for another time.
This is a guest post by Shinobi. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
