If you want to know how to structure an event, filter the relays for that kind number and look at the events it gives you, and then find a client that uses that event kind and look at what it does with it.
Don't need NIPs. Just need test data and a PoC or a spec, someplace. The main thing we now use the repo for is making sure the kind numbers don't clash, by listing them in the ReadMe.md.
Undocumented blackbox driven development does not sounds right to me. Anyway, thanks for explaining your point of view!
Verifying is the only way to be sure. Going by text (that no one is following in the same way) results in wasted dev time. In the end, actual verification will be needed anyway.
Fr. There is no traceability between NIPs and code because one group of people controls the NIPs and a different, sometimes overlapping, group of people controls the code.
Just look at the hot mess that is AUTH. If I opened a PR that attempted to fix that, it would never get merged. Everyone arriving new would go with the merged version, quickly realize it doesn't really work well, and then come up with variant #1946, which is incompatible with some of the other variants. And then maybe join me by also submitting a PR. Everyone can submit a PR, hardly anyone can merge, so the specs just rot and the PRs pile up.
I didn't meant that verification is not needed. What I mean is that instead of relying on the code from each client/relay introducing new NIP as a reference implementation, developer first define what they are imolementing and leaving reasoning of their decisions, and then implementing it.
We do that, but that has nothing to do with NIPs or GitHub. We write it on Nostr.
NIPs are only the ID numbers that you get assigned, if the NIPs repo merges your spec on GitHub. Otherwise, you have to devise your own numbering system (we use "NKBIP", instead of "NIP") and find some other place to store it.
LOL this is the dumbest take, fr. I didn't realize you're just a troll.
My English can be not sufficient to express my views precisely, but it is not a reason to mark me a troll.
You just claimed that I suggested undocumented blackbox development, as if the alternative were documented whitebox development.
The documentation and the development are not linked. They are not even necessarily written by the same people and the docs are nearly impossible to update, so the developers just do whatever, so you have to look at the code to stay interoperable.
