Nostr, a growing hub for the Bitcoin community, faces several incentive challenges if it wants to reach significant size.
This is an opinion editorial by Shinobi, a self-taught educator in the Bitcoin space and host of a tech-oriented Bitcoin podcast.
I have written an article about the basics of what Nostr is and what “events” are and how they work, as well as one of the main management issues that the platform needs to solve. Now, let’s look at some of the problems that relay servers will have in the long run.
The entire Nostr protocol relies on someone somewhere running a relay server. There is no “Nostr network,” only relays and clients connecting to relays. There needs to be an incentive for people to run relays, and in the long run, that will end up being a big part of relay distance. There will never be a Nostr relay on the same scale as Twitter’s servers unless it can be operated profitably or, at the very least, bring in enough money to cover its own running costs.
Advertising
Ads would be too trivial to be completely blocked, making it an impossible solution, given the way Nostr works as a protocol. A relay server can try and use advertising as a revenue model, it’s obviously the dominant revenue model for almost every free service there is online, but the problem with the users is that they have to opt in. Relays can easily inject advertisements into events sent to clients, but clients can also filter them out easily from the user interface if the advertised events are not generated by the public key they are intentionally subscribing to.
Even if the relay operator produces a client that does not, there is no way to prevent users from using other clients that retrieve data from the relay. They don’t even know whether their client is hiding ads from the user or not, and due to their lack of insight, this model is almost dead on arrival unless the user deliberately opts out. Even then, the relay operator will not have a voice base to show anything about the level of engagement for the advertiser.
Micropayments
Micropayments are another obvious solution, especially given the current effort to integrate Lightning more tightly into Nostr applications. This model will give you a lot of flexibility in how you charge. The relay can charge for just sending the event there, it can charge for downloading the event for reading, it can do a combination of both and set the price of each depending on the resources consumed by one or the other. However, I am a bit skeptical that this model can scale like Twitter. Micropayments content shows itself to be viable in many special things built in Lightning, but there are two fundamental problems with a global scale.
First of all, there is not enough Bitcoin adoption for that right now. Even if everyone would be okay with paying for every small service interaction through Nostr, there aren’t enough people holding bitcoins to support it on a large scale like Twitter. Relay can charge subscriptions via fiat, but the payment rail will not support fractional cent payments for each event sent or downloaded. Second, people have grown up using services like this for free. It’s just what people want. Micropayments alone I do not think will really cut to support relays on a larger scale as well.
There may be a way to make micropayments “stickier” or more sustainable without imposing on every class of user that uses your relay. There is a lot of discussion about building all kinds of applications on top of Nostr in addition to cloning Twitter: GitHub, Wikipedia, even decentralized gig worker applications like Uber. That last one is the key here. Something like Twitter or Google is just a service that people have been using all their lives for free. Economic commerce is not a place where these assumptions are deeply ingrained. People are used to paying a fee to post job ads everywhere, or paying a cut to market operators when ordering online. They just assumed and expected it from the beginning. This can give relays a way to create a trusted backbone of users without creating too much friction or breaking the expectations of the average potential user.
If micropayments are also going to be a factor, then relay operators will need to open a Lightning node in order to accept funds from users in the first place. This has the potential to expand that revenue if properly synergized with any micropayment model implemented. The bigger the relay server is in terms of the revenue it draws, the more liquidity is needed on the Lightning Network to facilitate it. If the operator plans correctly how to distribute or allocate the liquidity in the network, then the mere act of running a route node may be an insignificant revenue stream, in addition to whatever is charged to receive or send data through them. relay.
Can Nostr Scale Relay?
Although gluing all this together though, can a different revenue model support the scale relay of Twitter? Maybe relay gigs work, but isn’t it a rational step to specialize in just that type of event? What about other use cases, like social media? Maybe individual relays operating at that scale for certain Nostr use cases are not economically feasible. The basic structure of the protocol is implemented in a very simple way so that it is not easy to censor or destroy the content of the event in an obscure way. The structure comes with overhead, though.
That doesn’t fundamentally eliminate Nostr if it’s true. After all, clients can connect to any relay they want. Clients are not married to individual relays, they can take events from dozens of relays at once. Events stored on one relay may refer to events stored on a completely different relay. The protocol can still be used in any practice, although individual relay servers have limitations that cannot exceed the number of users or the number of events stored and served.
But… this dynamic presents its own problem of how to index and track all the data scattered across all the different servers. Do you have a complete view of a series of cross-referencing events? Is there something missing?
A distributed web of smaller relays will have the same scaling challenges as a single relay trying to become a large one. 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.