Nostr has been around for two years, and it has seen massive growth in that time. However, if we want to see long-term stability, we need to start marking key NIPs as 'final' and freezing changes to those specifications. This would give new developers a basic set of requirements for compatibility, and would improve the long-term stability of clients that are no longer in active development.
Discussion
Nips are a mess. There is no consensus. Without consensus, entropy will increase as nostr grows. This is what you are seeing.
Best we can do, imho, is fight the entropy itself, by proving understanding and communications amongst new and existing developers.
- Better documentation of NIP ecosystem will help.
- Documenting current best practices (real world workarounds) by developers will also help.
- With documentation, existing and in progress, having regular online dev meetups / brainstorms / idea talks / presentations / and such will also help.
Bathe steps, eyes forward, and always optimistic. This is the way.
Excellent points.
I believe nostr:npub1m3xdppkd0njmrqe2ma8a6ys39zvgp5k8u22mev8xsnqp4nh80srqhqa5sf is working on better documentation of the NIPs; his projects will be worth keeping an eye on.
Additionally, the next step beyond documenting best practices is implementing them. That's why one of my projects is a C++ Nostr SDK. Reliable, stable, easy-to-use dev kits will go a long way to fighting the entropy.
Well, code is just documentation that can be read and interpreted/executed by a machine. Dynamic documentation.
So, an SDK is essentially documentation of one project team's "best practice for implementation" of a particular NIP.
It's more reusable than a mere implementation in a larger application because it's "Just the NIP, sir".
It never ends.
Well, no protocol ever truly is completely finished, but it makes sense to document wider consensus, mark mature docs as "good-enough to finalize", and then not expect any broader application of them, until they reach the next "good-enough to finalize" stage.
There will always be some bleeding-edge implementations or experimental docs, but I'm not going to chase down every hare-brained scheme some developer came up with (regardless of how popular his client is), and solidify it in the SDK.
That's not what an SDK is for.
just fork nostr 🤣🤙 !
This isn't about forking it. Freezing is the opposite. It's a form of versioning.
We're going to be doing this from the SDK side, and every client does this by default, but there's no reason the repo owners can't offer some form of standardized configuration management.
It could just be a list saying "This set of NIPs in this version is the new widely-accepted standard."
They can still tinker around on the docs, but we can ignore that and stick to the list, until they produce a new list.
Versioning the protocol is a great step forward.