Replying to Avatar hodlbod

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.
Avatar
MichaelJ 2y ago

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.

Reply to this note

Please Login to reply.

Discussion

Avatar
hodlbod 2y ago

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.