Nostr is quickly reaching the Lone Wolf Horizon. Pretty soon it'll take a whole team of developers just to understand and implement all the relevant NIPs.
It's not hard to add to an existing client, but if you're trying to create a new one, ensuring compatibility with existing clients is a hefty piece of work.
More NIPs isn't the problem, it's adding complexity to existing ones (a tags, for example)
Can you elaborate on that? Are you referring to NIPs that redefine or expand functionality first defined in an earlier NIP?
NIPs get updated over time. Another example is zap splits. That was added after the fact, and is a poor spec. It adds complexity, makes existing clients not spec-compliant, and increases the hurdle required for new developers to implement zaps properly. NIPs should be entirely separate as much as possible, like NIP 89, which doesn't require anyone to know or care about it.
The best case would be for NIPs to be fully atomic. If a new NIP changes or replaces an existing one, that should be clearly indicated. The existing NIP exists for legacy purposes, but is clearly marked as deprecated so new development work focuses on the current preferred implementation.
That's basically how the existing web works. It takes a long time for changes to get to everyone (remember how long IE11 was supported?) but it ensures a consistent experience for older software.
In theory yeah, but I think it's more complicated than that. NIPs can be updated in place while maintaining backwards compatibility, so that's often ok. Atomic NIPs are obviously ideal, but many kinds of functionality have interdependencies and would be hard to keep separate. That's the scenario where you'd really need a migration path, but those are just so painful. We're going to witness that with NIP 04/44 this year.
Another problem is NIPs getting changed from under you. Ideally, once it is merged, it shouldn't change.
I distinctly recall looking at NIP-07, then returning to it a few weeks later and noticing a new optional method had been defined. It's optional, so not a huge deal, but something like that can affect existing client implementations.
A corrollary to reaching the Lone Wolf Horizon is that maintaining client libraries in various languages will become essential. NDK is a good start.
No one reimplements HTTP, they just use a library. Building those tools for Nostr will be the next big step.
