Nostr Web Client

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.

nostr:nevent1qvzqqqqqqypzquqjyy5zww7uq7hehemjt7juf0q0c9rgv6lv8r2yxcxuf0rvcx9eqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyrwldrvhdjm5f6htm8u673d5k5ah7lchj6v96calm2mg40kwt60qz38g2pu

nostr:nevent1qvzqqqqqqypzquqjyy5zww7uq7hehemjt7juf0q0c9rgv6lv8r2yxcxuf0rvcx9eqy88wumn8ghj7mn0wvhxcmmv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tcqyztw4tm9z2cp5f2fzctdgkgghaencfxl6huhhcnkckw639x6asnfvwn2knr

ManiMe 1y ago

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.

Reply to this note

Please Login to reply.

Discussion

MichaelJ 1y ago

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.

Laeserin 1y ago

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".

ManiMe 1y ago

It never ends.

Laeserin 1y ago

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.