Replies (46)

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...
Karadenizli's avatar
Karadenizli 3 months ago
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.
KotlinGeek's avatar
KotlinGeek 3 months ago
Please don't. It's now part of my muscle memory to look them up there. Thanks.
I don't think nostr is bootstrapped enough yet. I think once it's got legs, definitely delete it.
Nobody cares what you do with your repo. NIP IDs should hashes.
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. image
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.
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.
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.
U's avatar
U 2 months ago
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 ๐Ÿ‘ป
โ†‘