Okay, we're going to document which NIP versions we're implementing and ignore everything after that.
Shit is fucked up and bullshit.
Discussion
They say they are feature backward-compatible (because someone who already implemented software doesn't necessarily have to change it), but they aren't process backward-compatible because they change the scope covered by the individual documents.
So you can define your tool as being compatible with NIPS 771, 168, and 490, but not with any others. But if they then move sections from 771 to 107 and from 817 to 771, then you're not compatible with 771 or 817.
That's why someone who creates an SDK suffers most, because he can't use the NIPs effectively to define what his modules actually do, so he has to version his SDK with a particular configuration of the NIPs.
He can't just say "I conform to the mandatory requirements of NIP 771." because that might be a completely different document covering a completely different topic... tomorrow.
And he can't plan the implementation of NIP 14, 15, and 231 because those NIPs might
- disappear,
- be rearranged,
- be sliced and diced and
- have their content spread out to other NIPs, or
- be completely rewritten,
by the time he gets around to implementing them.
Even if it's only a matter of weeks.
Our SDK will be clearly versioned and conform to a particular configuration of NIPs, as defined by us.
Any changes, including breaking changes, will be implemented in new SDK versions covering a new NIP configuration, as defined by us.
This chaos is not the result of "innovation". You can innovate without making a gigantic mess of things.
This is simply poor process management.
1) The people managing the protocol repo also tend to maintain popular implementations, so the chaos keeps their competition down and they are prone to using the NIPs as the technical spec of their product.
That is an inherent malincentive of dual-market capture (the dynamic implementations and the static specifications) that should be controlled for.
2) It is not clearly defined what a NIP covers, so things keep being shoved around and rearranged. Does a NIP cover a technical topic, basic features of a particular implementation, a minimum viable implementation? Depends.
3) The NIPs change so often and dramatically, that new and smaller developers tend to focus on implementing NIP 01, so that their stuff simply works and they can at least produce one note that people can read.
But now the content of NIP 01 is being dramatically altered, without any wider discussion. That means most implementations will no longer conform or will have additional NIPs that they have to track.
4) Ain't nobody got time to read all that. KISS.
GM
it’s a chaotic process
Which is fine, if that's how they want to play.
But when you create an SDK, developers are depending upon you to defend their interests and implementations in the protocol discussions, and to pace the speed of protocol changes.
We can't just come out with a new SDK every week because people will be building upon it and we'd break their clients.
We have to bring some order to the chaos.
And we should ask ourselves, if some of the chaos isn't just chaos for it's own sake.
That's a common form of market manipulation.
We all hate duplicated efforts and wasted time. However much we want to avoid it , the hardest lessons come irl failures . That’s what it takes sometimes to line up the ducks
Open source code snippets create a forest litter and things grow out of there eventually