Avatar
Ryan
285d4ca25cbe209832aa15a4b94353b877a2fe6c3b94dee1a4c8bc36770304db
Father. Husband. Bitcoiner. Developer. In that order. Nostore: https://apps.apple.com/us/app/nostore/id1666553677 Nomen: https://nomenexplorer.com

Is there a way to use Nostr Connect on Iris when it is a PWA? The option disappears on iOS when I add it to the Home Screen nostr:npub1g53mukxnjkcmr94fhryzkqutdz2ukq4ks0gvy5af25rgmwsl4ngq43drvk

Replying to Avatar semisol

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 :)

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.

“Pretty please stop killing innocent people, but don’t worry, we won’t do anything at all if you don’t stop.”

There's a new, separate repo for Nomen specifications, and it's modeled after NIPs. They're called NOMs. I have opened a PR for a new NOM that allows indexers to publish their name data to relays, so that clients don't need to make external (or potentially proprietary) API calls to query names.

I would love feedback if any of you have interest in Nomen development: https://github.com/ursuscamp/noms/pull/1

It’s an extra output on top of any transaction. The size depends on the length of the name, but it’s quite small.

If you choose a 4 byte name “owen” then it would be 42 vbytes in total to register. That’s 4200 sats fee, or $1.54 at current prices + the cost for the rest of the transaction (it can be any transaction as I said).

Me and my entire family are heavily invested into the Apple ecosystem and not one single other person would change if I asked them too. Lol

If fees stay the same, should I implement Liquid support into Nomen? This thing will die if it can’t even get properly started because no one will buy a name because of fees!

The ordinals enjoyers seem to want me to step up my timeline for Liquid names for Nomen…

I am attempting to bring global, unique names to Nostr via an open protocol.

I wanted to explain the new release of the protocol (and reference implementation), and why it needed a backward-compatible upgrade. nostr:note1r8s9ack6xmjv8x4vc7ucsgn9vzu9c3kt3eky3pj7nupx70crz9xq90ancn

Hamas is not an existential threat to Israel. This campaign is about revenge, pure and simple.

What is existential to Israel is bombing the population of Gaza to oblivion, committing non-stop terror and violence against the citizens of the West Bank, and uniting the entire Muslim world against them. THAT is an existential threat to Israel, and they have brought it on themselves.

I prefer to borrow the str: &str

Released 0.2.0 of the Nomen Explorer today. Disabled transfers temporarily. Transfers in protocol v0 were broken, they will be fixed soon and released with v1 of the protocol.

Fixed the issue that double-indexed nostr:npub18n4ysp43ux5c98fs6h9c57qpr4p8r3j8f6e32v0vj8egzy878aqqyzzk9r name 😉

https://github.com/ursuscamp/nomen/blob/master/CHANGELOG.md

I don’t suppose you would be willing to provide the PSBT so I can open a bug ticket? If not, can you provide an alternative PSBT which generated the error?

iOS. I am behind the times maybe. Is there a solution?

I miss zapping posts