Oddbean

Nostr has a funding problem. Developers and infrastructure is severely underfunded and reliant on flawed economic models, and this could pose a risk to the future of Nostr as a protocol. To understand it, we need to understand what resources are needed to make Nostr work, how they aren't funded properly and what could happen next. # The costs of what makes Nostr work Nostr works because: 1. Developers build clients on it 2. There is infrastructure to support clients If there are no developers, there are no clients. If there is no infrastructure, clients have no purpose. ## The costs of developing a client, and the reliance on developers Clients require time to develop the client, and money to run infrastructure for it. Without developers, there would be no clients, and no Nostr. Developers have lives and need to make money somehow in exchange for the time they spend. Developing a client is a significant cost, even for small ones (assuming 1 hr/day, no infrastructure costs and the average salary of a software developer, **$1500**) and needs to be covered somehow. We have multiple models, all of which have large downsides: 1. Donations/V4V/Bounties: This model suffers from the problem that a minority pays for the majority, which will lead to the majority demanding exclusive benefits for their money or otherwise cutting off funding since they have no reason to pay. This also suffers from the fact that donations are unreliable. 2. Grants from OpenSats and similar non-profits: These suffer from the same problems as the donations model, but also suffer from the following problems: - the managers of these non-profits may have views not aligned with their donors, leading to misfunding. - that such projects are mostly stopgaps that add additional complexity to a direct donation model. 3. Paywalled features: It is very hard to find the balance between paywalling enough features to make money, and discouraging too many users from using the client. There may not even be such a sweet spot. 4. Cuts: It is extremely hard to balance these so that people don't complain, and it is likely that there will be forks of FOSS clients that remove these features by some users. 5. Paid clients: People do not want to spend a lot on services that they expect to be free or cheap, and spending $5/month on this client, $10/month on that client, so on won't scale, even though that is way less than the actual value they are getting. 6. Ads: Ads are usually underpaying and mostly make money for the ad companies instead of the client developers. Ads are also an invasion of privacy and may not be well received by some users. 7. VC funding: VCs put profit above protocol health, which may accelerate some issues that I will discuss later. They also may disincentivize the development of some apps (uncensored social media for example) for pushing their own agenda. Even if we find some good way to fund clients, it doesn't end there... ## The cost of infrastructure There are multiple types of infrastructure for Nostr, such as relays, services like Noswhere's search relay, push notifications, etc. All of these cost money to operate, and are the other half of what make Nostr work. These have even more limited funding options, which have even bigger downsides: 1. Client funding: Clients already struggle on funding as I discussed in the previous section. This would mean infrastructure is even more underfunded. 2. User payments: Users do not understand the details and importance of infrastructure, and have no reason to fund it. Making this problem worse, infrastructure providers can falsely advertise their services, diverting money away from infrastructure that is higher quality and should be funded. This is already happening. 3. Grants from OpenSats and similar non-profits (*relays only*): Again, these suffer from problems specified in the last section about grants. These entities will likely want the highest value from their donations, therefore leading them to encouraging a few big relays than many medium sized ones. Since relays are more important infrastructure, and they could have more control, these entities can also exert more control over the network. 4. Data harvesting and selling: This would discourage people from using their providers, but this is likely going to happen to some extent. The issue is that it would not generate sufficient revenue for the amount of users it will drive away. Both infrastructure and developers being underfunded can lead to issues that may kill the protocol, which I'll discuss in the next section. # The risks of improper funding ## 1. The protocol fizzles out and dies without reaching critical mass This is one of the less likely options since there will probably be people developing for the sake of it, but is likely. With client developers being underfunded and infrastructure shutting down, Nostr would become smaller and worse to use until it completely fizzled out except maybe a few people. ## 2. The enshittification of Nostr This is the most likely outcome, and the worst one. As Nostr continues developing, developers and infrastructure developers will want to maximize revenue, so they will begin by making good products to attract users at a loss. After they have a sufficiently large user base, they would slowly erode bridges to their competitors, only leaving what is required so that their users won't complain. After this stage, it is likely that clients will start merging with other ones to make larger "everything" apps and kill the last bridges, turning them into proprietary walled gardens, returning us to where we are today. # How do we fix this? I have no idea. Please share your opinions if you do :)

I don’t have all the answers, but users won’t come en masse because for the sole purpose of supporting devs. They will come for the content and the people they know and like. I use “content” very loosely, and maybe “activity” would be a better term. Activity could include consuming content, and it can also include creating content, playing games, etc. Content is king and will drive the economic engine of Nostr. How do “we” incentivize more content, more content-related activity, on Nostr?

This all comes back to discoverability around people’s interests. Perhaps people could pay for feeds that are curated by algorithms. I know everyone is very hostile to them by and large, but there are some positive aspects that can be salvaged. If they’re implemented in a more user focused way I think there are less downsides. Maybe I’m talking out my ass right now who knows.

Another issue, users will need ways to spend fiat. A 100% bitcoin-based economy simply won’t happen at this stage. There need to be more bridge services that allow normal users to spend from a credit/debit card, even if the receiver wants to receive in sats.

I would like to have zapfunding goals for every dev working on every aspect of nostr so we know where money needs to be directed. I’ve seen zap fund pooling in iris but I had this feeling that I was spreading my sats percentages out too much and I would rather focus on the devs that aren’t as funded as much as their peers if that makes sense. I know underfunding is a problem across the board. Would love to know y’all’s thoughts.

That's a big worry, because it's hard to run at a loss for long without financial incentives. It is also possible that as the number of users increases, the client can survive through advertising or other monetization methods, and the Relay operator can charge for providing personalized database services. Nostr is a new thing, and maybe in the future, there will be large Relay and client companies, just like Bitcoin. Individual users who want to save their data can run small relays on their phones. So there are large clients and Relay to provide quality services and optimized infrastructure. Even if large enterprises fail or are censored, individuals can run their own relay and use free and open source clients to continue to function. In this way, both high-quality services can avoid the single point of failure ecology of large enterprises, which may be a sustainable decentralized healthy ecology of #Nostr

jack's donation provided fuel and launch systems engineering infrastructure for the #Nostr rocket. Now that the Nostr rocket has taken off, we have some time to fly before we can escape the censor's gravity. Looking back over the past year, we've been flying fast. I believe we can quickly fly out of censorship gravity and reach the freedom universe.

This is something relevant that Jack Dorsey said: “In the 90's, as more and more people got onto the Internet, one of the problems that a lot of companies tried to solve was the discovery problem: IRC and Usenet and SMTP e-mail and the web were all inherently fairly decentralized as long as you could host a server and find what you were looking for. Google comes along — and Facebook and Twitter — and centralizes discovery. But unfortunately the centralization of discovery also meant centralization of data ownership and monetizing that — because they're companies - which led to the ad model and putting almost all the eggs in that one bucket, without doing a proper exploration of other models that could work. And those incentives — of course then going public and having shareholders — created a particular direction in the momentum that was very difficult to get out of. That was definitely my experience at Twitter: we built something that was entirely — and still is entirely - dependent upon brand advertising. And you're in a class of companies where you are seen as this - by advertisers — their budget is really seeing you as a nice-to-have but not necessary, because you're so small relative to the giants. And that puts a lot of pressure on how you develop, what systems you build, what content is on the network. And to me it really all came back to the fact that we were both the client and the protocol and the hosting of all of it, which put a single point of failure in terms of how people used it — and the single point of failure was ultimately the company. So in retrospect: when we were just an API and we were a fun little project inside of another company — those were the glory days.” https://chowcollection.medium.com/bitcoin-review-podcast-br018-nostr-deep-dive-panel-with-nvk-ft-c9e43c260679

Sorry, I Will explain you why 😅 If I have problems trying to consistently fund a relay, I just make a fund with some bitcoins in it and spend them in a convergent series of polynomial decay. With polinomial decay(e.g x^-2) your funds are depleted polynomially BUT also your expenditure decays polynomially. If we assume the value of bitcoin grows exponentially, then both (my remaining funds and my expenditure in some point of time) grow exponentially in real world value because the l'hopital rule. If my expenditure and my hodling grow exponentially at the same time, it means funding infrastructure or devs is not a real problem in terms of magnitude of wealth (maybe it's more an organizational problem🤷)

We should rebalance our priorities to favor relays more. Relays being transparent is a mistake for long-term sustainability. Relays should be communities. Relays should be invite only for posting, or have some membership requirements. Clients should obviously display which relay a note was from, and you should select destination relays when you make a post. Clients should also offer optional filters by relay to allow users to delve down into more specific communities. The goal here is to be more like IRC, which maintains infrastructure for free for decades by being more “community-like” with regard to relays and making sure power users have a stake in the relay. We should not be as siloed as IRC, however. Client integration with multiple relays should find a balance between making the seams between relays obvious but not a hindrance to UX. We should maintain the look and feel of global feeds while fostering per-relay communities.

This is a problem, one I think about all the time. We need to become more creative in our approach to this, and consider the funding option from the user perspective first. People will spend, if there is simplicity to it. Users don’t want to fund clients, then relays, then features, then add one, then peers, etc. Funding the infrastructure should be simple, and it should have an incentive. I don’t know how we could break down the metrics, but it would be an easy justification to fund my core use, clients and relays on a streaming type of approach, per use, say x sax per minute for client usage, or a subscription case for good relay operators. I think a rebate incentive is good as well, something where the user gets x percent of the pot at the end of the month in return for using the client as a sort of bonus. I understand that this could mean that some data collection would be necessary, but putting out my 2 sats for 💡 creation.

Charge creators to utilize the apps/clients, or take a commission from their earnings, etc. Serious creators are more business minded and willing to pay for a service that nets then a profit. If creators (writers, musicians, videographers, photographers, etc) see that they have a good chance of monetizing their content then they’ll be incentivized to pay for access to features. User subscriptions for premium services aren’t abnormal either, even if there’s a free tier.