I'm seriously considering deleting the NIPs repo. What do you think?
Login to reply
Replies (46)
Just do it!
Please do not. I keep forgetting what the stupid algo's name is for the key generation xD. It's faster to just dash to the NIPs than to dig around the bitcoin org...
๐๐ What is the purpose of your idea
YOLO
I think John and Vitor will continue
Nips should be published as their own nostr kind, client devs should publish signed collections of the NIPs they incorporate. Then you (and others) should make a website that lists all NIPs, along with compatibility chart of major clients that incorporate it, and those that don't. Similar to the firefox browser compatibility table on the CSS docs.
So instead of having an authoritative list of "official" NIPs, you have a much longer list of NIPs, but on each one it shows client compatibility so you get an idea of your reach.

Send it LFG
Maybe just archive it? A lot of us use it as a reference and it's easy to read
I will republish it, even more centralized than before
We need something better first, and you've already said nostrhub isn't it
Cool, but merge my Nip first.
Please don't. It's now part of my muscle memory to look them up there. Thanks.
web searches always lead me first to here: -- who runs this? This seems to be out of date? Can someone remove that if so? This is the one I want to get to: 
Nostr | NIPs
Documentation site for NIPs
GitHub
nips/47.md at master ยท nostr-protocol/nips
Nostr Implementation Possibilities. Contribute to nostr-protocol/nips development by creating an account on GitHub.
put it as #NDN
I don't think nostr is bootstrapped enough yet. I think once it's got legs, definitely delete it.
You just described atproto lexicons pretty much.
The fact that you can delete it is more than enough reason to delete it.

I've also already said what is.
To answer your question it would be useful to have any link to a reasoning (if you have provided that previously).
My problem is not the centralization, my problem is with the format. It's not good for what it has become. Also the cognitive load and confusion.
Nobody cares what you do with your repo. NIP IDs should hashes.
This: View article โ
Would the "guides" be linked from the kind numbers repo? Honestly this change doesn't sound bad, but I don't have much stake here.


We've talked about so many alternatives I can't remember which one you liked and whether it exists
There is no NIPs repo ๐ฅ
It seems much more sensible, since GitHub is still widely viewed, to maintain it as a gateway for those just starting to learn about the Nostr and the Nips.
And just add links to the right places.
Ack
Noooooooo, I discovered nostr through those notes and they were my goto place while I implemented my relay. WHy would you want to do that?
Just random people writing guides of "how to do whatever on Nostr" in any format they want.
Can you please not do that? Nostr is an unstable inconsistent mess as is.
The greatest gift Satoshi gave us was going away.
What the hell is a NIPs repo and why have I never heard of it before? ๐ฉ
No, they wouldn't.
And I'm not sure we need a kind numbers repo, although that sounds like a good, harmless feature to me now.
you should, and then someone else should recreate it, disproving your centralization hypothesis
I've seen discussions about alternatives, but no consensus. Shouldn't we have the new boat first, before we sink the old one?
It might be that 1,00 people building alternatives evolves a better format; it's even odds that everyone will just drown. I think it'd be safer to toss the golden apple into the room if Nostr were more established.
So the question becomes discovery of the specs? It would be great to have some at least decent solution, otherwise all new devs will hate it.
It's a feature.
Punk AF. ๐ฏ

Some of those issues I can diagnose from this photograph of nostr:
1) Sometimes our wires gets crossed
2) Usually we are not talking from deep down, but that changes when we are at conferences
3) Take care to avoid the triangle hazards
4) Relays will gossip
There are really basic things being discussed, still.
It's fine not to have secondary things in the repo, but core stuff should be sorted out and a central repository is especially important for newcomers.
Consider how many times the standard for quoting events has changed, drastically.
If you had gotten stuff right at first it wouldn't matter as much, but the repo is still serving its goal.
I think future devs/maintainers will be happy to find at least some grave yeard archive of sorts, to be able to understand legacy code ๐ป