Thread

we need more nostr pundits

So funny enough, nostr:nprofile1qqsypwwgtll74lqu4huvxzjwtjyxvrlkujt35rw8y026ke6ttesmg5gpzdmhxue69uhhwmm59ehx7um5wghxuet5qyvhwumn8ghj7un9d3shjtnwdaehgunrdpjkx6ewd4js8anlf3 was actually a key player in forming the nostr:nprofile1qqsyda3mvuruue6fvl3nq2p39d8espqee26zppfs7u3sx8jd7ccrayqpzamhxue69uhhyetvv9ujumn0wd68ytnzv9hxgtcpr9mhxue69uhhyetvv9ujuumwdae8gtnnda3kjctv9uzg7kst group 😬. Though he’s moved on to other projects now, he wrote the first draft of the de-commerce spec. Anyway, I agree with the concern that formalizing Nostr development risks centralization in and of itself. But I don’t think a top-down structure is being proposed here. We could actually agree on some basic ground rules in a decentralized / bottoms up way by going along with simple ideas like dual layer spec, formatting and attribution. This issue is: who approves what’s “core” and what’s “outer layer”? The answer should really be: *nobody*… but then how do we know as development teams what efforts are experimental and what are essential? Right now there’s a kind of Nostr “shadow governance”. A sort of *cool kids club* that decides, without much public discourse, what is in and what is out. When you’re developing something today, you’re already playing politics with this group either directly or indirectly. Luckily, this group contains (for now) excellent people who all seem to care deeply about decentralization, freedom of speech, etc. But people are fallible, and the status quo is unsustainable: the *cool kids club* only has so much bandwidth, so naturally they focus on people and projects they already know, and people who enter the space from the outside either: 1) get frustrated by the lack of attention and leave Or 2) start playing the game, politiking to the *cool kids club* (Or maybe 3: form your own equally *cool* club like Gamma Markets and try to make allies with the current *cool kids club*) In the absence of a declared structure, we already have a bit of a governance problem. This is natural and not necessarily bad… sometimes I think maybe it’s the way it needs to be like you alluded to in your post. But overall I tend to agree with nostr:nprofile1qqsypwwgtll74lqu4huvxzjwtjyxvrlkujt35rw8y026ke6ttesmg5gpzdmhxue69uhhwmm59ehx7um5wghxuet5qyvhwumn8ghj7un9d3shjtnwdaehgunrdpjkx6ewd4js8anlf3 on this issue in some ways: SOMETHING is probably better than the current “nothing” (which is actually not nothing and a form of crony governance formed in a structureless vacuum). I don’t think he’s proposing a top down structure. Maybe I’d add that there’s something missing from his suggestions: a way for us to decide in a decentralized way what is “core” and what is “experimental”. Because without that, then yes I agree we’d be appealing to a centralized authority again (like we basically are already with the *club*). I don’t know what this might look like. Maybe a set of criteria that can be evaluated by multiple “watching” parties, like open publications, that don’t all agree on the exact set of “core” implementations but allows the observer/reader to see some convergence. Anyway, I’ve arrived at my destination so I’ll shut up now. Thanks for tagging me and giving me a bit of morning mind exercise. Cheers.

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.

> "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.