Oddbean

PSA 🚨 Without a direct innovation in the monetization structure of #Nostr I think we should expect a highly successful #Nostr to evolve like other protocols before it. I think there are 2 most likely comparisons: 1. #Nostr ends up looking more like email. It is still open and decentralized, but dominated by a small group of companies with enormous insight into everything that is happening and acting as huge semi-centralized custodians of everyone's data and messages. 2. #Nostr ends up looking more like RSS & podcasts. It is open and decentralized, but most users and all serious content creators pay for hosting platforms (relays) that sell it with a bunch of other features, analytics, and secondary services attached to it - or built in advertising and monetization splits. Understand I'm not predicting that it will go either direction or that only these two options exist. I'm saying that --- without a significant innovation in the monetization method --- it will very likely take one of these two paths. Also understand that neither of these are bad outcomes, per se. Both present a VASTLY better internet sovereignty and user/server power dynamic than the current Web 2, but this is far from realizing #Nostr's true potential. I only say this to get people thinking about the fact that we still have a very serious problem funding relays at scale, and it hasn't been solved, it's mostly been covered up with some very generous grants and *extremely* generous volunteer developers and relay runners. But it WILL have to be addressed or nostr's success will come hand in hand with some hard truths about how we use it and what we think it is. It won't be unlike the people who thought all #Bitcoin transactions were going to be free forever, settle instantly, and that the whole world could be sovereign with their own UTXOs. That's simply not how it worked, and we had to have a 4 year, vicious, all out civil war within the community when we were finally forced to come to terms with that reality.

I basically agree, but also relays can be funded as loss leaders by other companies. Although that's probably consistent with case #1. A very difficult thing about relays is helping users pick good ones for good uses cases, which requires knowing the use cases. Operators are slowly closing down their relays to free use, or certain event kinds. The solution isn't to use a single paid relay, but to find which relays _want_ certain kinds of content.

We need custom nostr hardware like these cool bitaxes. A premade nostr relay that includes your own personalized nostr.build for Media hosting. Then people could more "easily" get in the game. Bonus points of the hardware runs a Bitcoin node and lightning mode but baby steps first. I wrote about this a little bit last night. nostr:nevent1qqsyf5u9cc3pwkrmxyrkpd9vxt8khh8m427xmc8wq5h8zmdvwag9atqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsygqwa7tpjl6ud03ctxmgzln22umxskzkcstw9x3fyk7459dj547gkypsgqqqqqqst79k5h nostr:nevent1qqst4q8rhx9e3ctu3vqz0tuywuekm8rxsd0h56d2dtr2zewt23mpprqpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsyg9euaj5dwsxg4hdxqweu54uf8ay3ec2d0ezs2l85xh899rkzgprmspsgqqqqqqsk0l2jw

I complete agree that we don't yet have a long-term viable economic model for nostr. But even as I say it, what is that model for http, smtp, torrent? There isn't really one. What we have are killer apps, or more accurately, killer businesses that were built over these protocols. These businesses are centralised, by their very definition, though they eventually cluster into ecosystems, and perhaps nostr makes that bit interestingly different in that businesses *may not* need to evolve in a cannibalistic, scorched-earth manner in order to be viable, but rather focus on being good at what they offer and good for the ecosystem... I think about this a lot as I pursue a business idea on nostr, and as much as I love the enthusiasm, the energy and the relatively high IQ density here, it's also clear that we're not close to escape velocity yet.

The monetization structure(s) that will support relays will depend on apps that serve the needs of customers in such a way that those customers are willing to pay for features, analytics, etc, in order to themselves be profitable in their own endeavors. Customers can be artists and content creators and vendors, etc, but customers can also be advertisers and others interested in user data for various reasons. App/client devs need to decide who is their customer base and intentionally build for them, instead of just building whatever willy nilly new feature feels cool to them at any given moment. Some seem to be better at that than others, but all of them who are serious about the future of their apps need to be thinking beyond their own pet projects and features to the needs of their existing and/or potential customers.

I think the more we are becoming like Oceania, accelerating towards a totalitarian world government, the more valuable will the #Nostr/#Bitcoin combination will be in terms of free commerce and free speech. I think it’ll be less of social media/entertainment, more like key infrastructure of the resistance.

Stop copying the business that run on ad revenue. We need apps that are worth purchasing. I see Nostr as the digital ID system of the the new web. And the apps will use Nostr, and http, and TCP, UDP, web sockets, Lightning. What is the first Paid App with a nostr login?

> “Stop copying the business that run on ad revenue.” I agree, I’m not suggesting that people use the same business model. To the contrary, I was explicitly suggesting that this is the area people need to be thinking about. Right now the old business models remain the only ones invented that have been proven sustainable. This is where we need to big breakthrough and we have the tools we need to experiment.

If I'm a relay operator and I don't want to die, here the future I want to see: - Client A, B, C. - Client A and B have implemented an Ads NIP, but Client C didn't. - User X has enabled to view ads. - User X has saved my relay to read/write from it. - User X used all 3 clients. - User X will see ads in Client A and B, but not C. - My relay would service User X in Client A and B, but not C (it wouldn't fetch from it or write to it). - When User X sees an ad in Client A or B, said clients would receive a percentage cut from the budget sent out to run that ad, and my relay would receive a cut, and the User would also receive a cut. - User X disables viewing ads in his metadata. - User X cannot see notes from my relay anymore, from any client, regardless of if the client has implemented the Ads NIP or not. With this, i'd also try to support as many content types as I can without going into the red, but I'd also have a block list to block clients that implement the Ads NIP but hide ads, or present them unreasonably. nostr:note1xt9z2c4u85kqrpru3fajmejpvc2kx9yg3m759zczy8caeez0kweqw7jupt