Here we go: https://github.com/fiatjaf/nocomment/pull/16
As far as standards go, nostr is famous for its accessibility. And many in the community - including me - think we need more nips, not less.
Why do we need [07.md](https://github.com/nostr-protocol/nips/blob/master/07.md)? Well, it helps those working on browser clients and browser extensions to coordinate their efforts. If you are not working with the browser, you can ignore that nip just like I would ignore other nips that - thanks to my contributions to their discussions I'm even featured as co-author of.
I agree that some see nips as "validation for their app ideas" and that's problematic. It's also why the [Readme](https://github.com/nostr-protocol/nips) states as first "Criteria for acceptance of NIPs": "They should be implemented in at least two clients and one relay -- when applicable." and sometimes we ignored Rule 1.
But formalizing ways of doing things help with interoperability. So I'm all for a nip on how chess clients work. I see the problem in the centralized repository where such a nip would be a distraction. The Jester guy would care about such a nip. Not me. But just as I care about the interoperability of social clients, I very much hope for interoperability for long-form clients like Habla or for ride hailing apps.
If not on GitHub under Fiatjaf's reign, where to best [consolidate implementation proposals](https://habla.nostr.info/a/naddr1qqdxsmmh23h5xmmwwdhkc6tyv96x2nr0den5vmmjd4zkuqg4waehxw309aex2mrp0yhxgctdw4eju6t09uq36amnwvaz7tmwdaehgu3wvf5hgcm0d9hx2u3wwdhkx6tpdshszenhwden5te0ve5kcar9wghxummnw3ezuamfdejj7mnsw43rzemdxa682anj89shgcekw5mhzvm8v4mx5en909n8jandwfk82mp50ymrw6ehw5mkscmc0f685d3hvdjk27rnxqmnsunxxclkyun0v9jxxctnws7hgun4v5q3zamnwvaz7tmwdaehgu3wwa5kuef0qyg8wumn8ghj7mn09eehgu3wvdez7qgwwaehxw309ahx7uewd3hkctczypr0e03svh40rtncz9r9jf8y3y3nv0ln75nt6mmn6lqcfvttmr8y6qcyqqq823cgtg38y) though?
> If you are not working with the browser, you can ignore that nip just like I would ignore other nips that
In theory yes, but in reality how do you know that before you at least glanced at it? And there's so many of these NIPs already that it takes a toll. It isn't scalable at the moment.
I personally feel a big mental strain just looking at the nips repo: wouldn't want to invest time into that. How many people actually know what's going on in the big picture?
Mostly I just install a library and hope the doc comments tell me what I need.
Which brings me to my point: I think the rule for acceptance should be "implement a library (or add functionality to existing) to deal with the NIP". Then I wouldn't have to care to read any NIPs.
I made this: https://github.com/npub1zenn0/go-git-nostr
I think it ticks all the boxes.
After some time developing on nostr, "simple protocol" makes development a real pain. Nostr isn't picking up steam anytime soon. Less devs => worse UX => slow death.
There is a need for good frameworks/programming libraries, but from the experience of Ethereum web3, I can confidently state that no breakthrough libraries are on the horizon.
I'm thinking that NIPs should be gatekept by introducing libraries to deal with said NIP first.
Will it be enough to create a web app that scans through relays on the client-side? It will not work for TOR relays then.
testing
> self-host the library using this link
link's dead, though I can see it was supposed to lead to "https://github.com/coracle-social/multiplextr"
Holy moly the UX of the first 2 nostr clients I try is atrocious. Make a post and nothing happens. I cannot tell if my post went through or not.
Whoever is the developer of primal.net, I have a feature request: please add `draggable=false` to replies, so I can copy paste text.
Also I would flip post/cancel positions but that's just me.