nips
nips copied to clipboard
nostr-protocol
NIP-7 lacks version control for the provider API
Hello. The purpose of this issue is to discuss the lack of version control for the provider API established in NIP-07, how to potentially address it and maybe solve it.
Without version control, the provider API will become increasingly impossible to upgrade or support over time. I don't believe anyone will disagree with this sentiment.
I'm not sure the best way to solve this. My humble suggestion is to switch to a JSON-RPC style interface, which does include versioning (and subscriptions). Many web3 providers used a similar interface under the hood (as both bitcoin and ethereum uses JSON-RPC) and it worked great.
Regardless of what the solution looks like, it would be a great opportunity to work on a more robust signing API in general, as signing devices will eventually have to exist outside the browser domain, such as a hardware device or remote machine.
What are everyone's thoughts on this subject?
There is no version control on purpose since that's just a sneaky way to introduce breaking changes as if that was ok. It is not ok. Backwards-compatibility must be achieved at all times.
If you really want a new thing that is not compatible with the old things, then you need a new NIP, with a new name and a new set of goals and purposes.
There is no version control on purpose since that's just a sneaky way to introduce breaking changes as if that was ok.
This is a radical statement. I'm not sure how to respond to this rationally. Are you throwing version control under the bus?
If you really want a new thing that is not compatible with the old things, then you need a new NIP, with a new name and a new set of goals and purposes.
That is not the issue here. The issue is detecting whether new features are implemented. I can't tell if a method has been extended without doing some sort of ugly hack.
Honestly if your take is that version control for APIs is stupid, then this NIP is pretty much dead. That would be really sad. I hope you can be more reasonable about this and see where I'm coming from. I'm trying to help solve a real problem here, so that myself and others can continue to contribute to the protocol.
Context: I am the developer of https://blowater.deno.dev, it's a web client.
To achieve the same purpose, instead of version control, we probably need to come up a set of acceptance tests for extension API providers. Because extension API is already across program boundaries, they should be treated as a remote API.
I can write the tests and open source it either under my own repo or under this org. And client developers and extension providers can all join the discussion.
A way to signal "I have this feature" is different from saying "I'm version 2, I don't speak version 1, you must upgrade". We should avoid the latter so that all existing components can keep working and are not forced to upgrade, ever... while the former of signalling a new feature should be ok. I once confused these and stormed out of the room in a huff when I first heard fiatjaf's stance... but nostr has NIP-11 which is a form of versioning that doesn't require anybody to upgrade.
I hope this distinction is correct; I've been wrong on a few things today though, this isn't my best day.
