Thread

Zero-JS Hypermedia Browser

Relays: 5
Replies: 5
Generated: 08:14:29
avatar
Five five@satshoot.com npub16p8v...fhdw
> "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 ↓
Login to reply

Replies (5)

avatar
Gzuuus gzuuus@nostree.me npub1gzuu...a5ds
Ok, seems we touched a nerve. We can agree to disagree; that’s fine. My argument in the article is that Nostr needs a better governance model to foster collaboration and provide clarity for newcomers. I mentioned Fiatjaf’s article because it’s another example showing that the community already recognizes problems with the current model. From my point of view, Nostr needs clearer guidelines and specifications if it expects to be interoperable within a wider ecosystem. The “wild west” approach can remain for experimentation, but that’s why I mentioned the dual-layer approach used in Lightning (BOLTs and BLIPs). I think a similar approach could help people and communities feel comfortable building on Nostr and make it easier for newcomers to participate. It would also help defend and harden the protocol against political and influence attacks, something I think is quite feasible. In fact, rejecting any governance model increases the chance of capture by an organization that can exploit the general confusion and discomfort about “how the hell do I build on Nostr” without having to dig through hundred of unstructured threads, discussions, issues, and PRs to just grasp the rationale and philosophy behind the protocol. If you read my article with fresh eyes rather than getting triggered, you’ll see that my proposals and key guidelines are intended to improve the clarity of the spec documents, restore attribution to organically create reputation, and define clear lifecycles for new proposals that expect to be interoperable. I’m not advocating for a “Nostr steering council” or anything like that. I mention these projects (peps, rfcs) because they effectively manage large ecosystems; even if Nostr isn’t that large yet, it will need some structures if we don’t want it to collapse as it grows. Also, Conway’s Law describes a symptom of capture: complex projects tend to take the shape of the organizational structures that design them. This ties into the “embrace, extend, extinguish” methodology I mention in the article. In short: it’s not about bureaucracy, it’s about resilience. PS: LNURL specs are confusing too
2025-09-18 09:51:02 from 1 relay(s) ↑ Parent 1 replies ↓ Reply
avatar
Five five@satshoot.com npub16p8v...fhdw
I don't know how you conclude you touched a nerve but as you might have noticed I argued against your points, not you personally. No hard feelings man, I just think you are wrong, at least based on what I read. If I got you right, in your world we need an overarching framework with guidelines as to how we extend nostr. In mine we don't. We will still definitely have a lot of well-constructed explanatory docs about design, just not standardized by anyone. People still have the incentive to get contributors into projects just they don't have the bureaucratic process of NIPs, and a "guiding body of experts" that are appointed to cast judgement on how people write their software. You can create such a thing, it's just that I doubt any serious player needs that when we have each others npubs. Or maybe some people will find value in that. More power to them.
2025-09-18 11:08:47 from 1 relay(s) ↑ Parent 1 replies ↓ Reply