Nostr, a growing hub for the Bitcoin community, faces some incentive challenges if it is to achieve significant scale.
This is an opinion editorial from 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 the platform will have to solve. Now, let’s go over some of the issues that relay servers will have to address in the long-term future.
The entire Nostr protocol depends on people somewhere running a relay server. There is no such thing as a “Nostr network”, there are only repeaters and clients connecting to the repeaters. There needs to be incentives for people to run relays, and in the long run, that will ultimately be a big part of how far relays can scale. There will never be any Nostr repeaters on the same scale as Twitter servers unless they can be operated profitably or at least bring in enough money to pay for running costs.
Advertising
It would be very trivial to completely block advertising, which makes it a non-viable solution, since Nostr works as a protocol. A relay server could try to use advertising as a revenue model, obviously it’s the dominant revenue model for almost every free service out there online, but the problem with that is that users would essentially have to opt-in. Repeaters could simply inject advertisements into events they send to clients, but clients could also easily filter them out of the UI if the advertisement events were not created by a public key they intentionally subscribed to.
Even if a relay operator produced a client that didn’t do that, there’s no way to prevent users from using other clients that did to get data from their relay. They wouldn’t even really know if someone’s client was hiding ads from users or not, and because of that lack of knowledge, this model is pretty much dead unless users intentionally opt-in. And even then, the broadcaster would have no solid basis to show anything about the level of advertiser engagement.
Micropayments
Micropayments are another obvious solution, especially given current attempts to integrate Lightning more tightly into Nostr apps. This model would offer a lot of flexibility in terms of how you load. Relays could charge just for posting events there, they could charge for downloading events to read, they could do a mix of both, and adjust the price of each based on how much of their resources were consumed by one or the other. However, I’m personally a bit skeptical that this model can scale to the size of something like Twitter. Content micropayments are proving viable in a lot of niche things built on Lightning, but there are two fundamental problems with actually scaling to a global size.
First, there is currently not enough Bitcoin adoption for that. Even if everyone magically agreed to pay for every little service interaction on Nostr, not enough people have bitcoins to support it on a scale as massive as Twitter. Repeaters could charge subscriptions via fiat, but those payment rails won’t support paying a fraction of a cent for each event posted or downloaded. Second, people have literally grown used to services like this being free. It’s just what people expect. I don’t think micropayments alone are enough to support large-scale streaming.
There might be a way to make micropayments “stickier” or more sustainable without imposing them on literally every class of user that uses your relay. There’s been a lot of discussion about building all sorts of apps on top of Nostr plus a Twitter clone: GitHub, Wikipedia, even decentralized apps for freelancers like Uber. That last one is the key here. Something like Twitter or Google is just a service that people have spent their entire lives assuming is free. Economic trade is not a place where those assumptions are deeply ingrained in them. People are very used to paying a fee to post a job ad somewhere, or paying a cut to a market operator when they order something online. They just assume it and expect it from the start. This could offer repeaters a way to create a reliable revenue backbone of their users without creating a great deal of friction or breaking the expectations of the average potential user.
If micropayments are also going to be a factor, then the relay operator will need to run a Lightning node to receive funds from users in the first place. This could potentially amplify that revenue if properly combined with any micropayment model that implements a relay. The bigger a relay server is in terms of the revenue it generates, the more liquidity it will need on the Lightning Network to support it. If carriers properly plan how they deploy or allocate that liquidity across the network, then just running a routing node could be a non-insignificant revenue stream in its own right, on top of what they charge for accepting or delivering data to through your network. relay.
Can Nostr scale relays?
However, even putting all this together, can these different revenue models support broadcasting at the scale of Twitter? Perhaps a work-for-hire relay could, but wouldn’t it be your rational move to specialize only in those kinds of events? What about other use cases, like social media? Perhaps a single relay operating at that scale for certain Nostr use cases is simply not economically viable. The basic structure of the protocol has been made very simple so that it cannot be easily censored or the content of its events altered in non-obvious ways. However, that structure comes with overhead.
That doesn’t fundamentally break Nostr at all if it ends up being true. After all, clients can connect to as many repeaters as they like. Clients are not married to any single repeater, they can take events from dozens of repeaters at a time. Events stored in one relay can even point to events stored in entirely different relays. The protocol can still work for any use case in practice, even if individual relay servers have hard limits that they cannot scale further in terms of user counts or the number of events they are storing and serving.
However… this dynamic raises issues of its own about how to index and crawl all that data scattered across different servers. Do you have a complete view of a series of events that reference each other? Something is missing?
A distributed network of smaller relays will face scaling challenges just like a single relay trying to be massive. But I’ll save it for another time.
This is a Shinobi guest post. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
