Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 1
Generated: 08:17:54
I think you are missing the point. I don't know whether it's because you didn't fully read the article, you weren't paying attention while reading, or something triggered you. But I'm not talking about formalizing Nostr development, I'm talking about governance and a process to propose new interoperability standards. If you read carefully, you'll notice that I treat that distinction with care. No one can impose anything on Nostr, no top‑down imposition; that will never change, but it's different when we expect interoperability: that's when we need a more robust framework. It also doesn't matter whether it's about money. Some of the projects with more robust and successful governance that I mention in the article (Py PEPs, Rust RFCs) are unrelated to money, and yet they designed a pretty good way to manage their project with thousand and developers, stake holders and participants, so I don't understand your rationale there. Anyway, I'm just reflecting on how weak governance can be an attack vector, and how better-designed guidelines and processes can help us be more resilient in the long term.
2025-09-17 16:17:37 from 1 relay(s) ↑ Parent 1 replies ↓
Login to reply

Replies (1)

> "The informal processes that served the early community are now strained, and my concerns about Nostr's long-term sustainability have grown alongside the protocol." By development I mean the design, discussion and implementation of Nostr protocol extensions in software that speaks Nostr. I say we don't need more governance and you say we do. Did I misunderstand something? I reacted on your Bitcoin claims because those were better for your arguments. I think Python and Rust made your case even weaker. Do you really want to introduce a "Nostr Steering Council" (Python) ? Or do you think the Rust Foundation provides a good model for governance of Nostr? Development processes of these are permissioned by their respective authorities. The article you mention ["The End of NIPs"](https://njump.me/naddr1qvzqqqr4gupzqwlsccluhy6xxsr6l9a9uhhxf75g85g8a709tprjcn4e42h053vaqqyrxvf3vgunjwt9lequnc) by nostr:nprofile1qqsrhuxx8l9ex335q7he0f09aej04zpazpl0ne2cgukyawd24mayt8gprfmhxue69uhhq7tjv9kkjepwve5kzar2v9nzucm0d5hszxmhwden5te0wfjkccte9emk2um5v4exucn5vvhxxmmd9us2xuyp argues for less structure in Nostr development guidelines and against numbered documents like RFCs and such, specifically mentioning how his work on LNURL is very different from Nostr: > ... "Then I just copied that approach to Nostr, I'm not sure if I thought Nostr was always going to be a single main flow (text notes) but it clearly isn't and hopefully it will grow to be even less like that. Nostr also **clearly isn't like a single-implementation programming-language-spec** with a dictator and his committee on evaluating random "improvement proposals". So we're forced to conclude that the **numberered-documents approach isn't the best way** to do coordinate the creation of Nostr-based sub-protocols." You failed to address a host of these nuances in your article (and a lot more others) and the "I just wanted to point out sth" approach is not enough when you provide bad examples to start doing things differently, in my opinion. If you ask me, OAuth, DNS and SMTP centralized because of Conway's law and not because people should have put more guards to safekeep their precious protocol. Design and implementation happened under the control of big corporations and/or governments, which already were centralized and burdened with bureaucracy. Vote with software, not documents on governance is my argument in a nutshell. Nostr was not designed by ignorant bureaucrats so I don't see the future your prophesies predict. I might be wrong about what you want to do, go for it and we'll see.
2025-09-18 07:57:45 from 1 relay(s) ↑ Parent 1 replies ↓ Reply