Add feature support signaling

[staab]

A few different conversations in the last few weeks have made me re-think my position on deprecations. I naively thought that:

• People developing applications would want to keep them up to date
• If they opposed a change, they would participate on discussions on github
• It is acceptable for clients to encourage others to upgrade by dropping support

This turns out not to be true, and that nostr currently has two ways to support protocol feature deprecations:

• Merge a PR, update some clients, and break everything without getting developer input
• Never deprecate old features

Our most successful deprecation to date that I'm aware of is the old #[0] notation for mentions. However, more-speech still publishes notes with this notation. It seems to me that "never deprecate" is the only option that will ever really work. But I'm not ready to give up on deprecations yet.

This PR adds a signaling mechanism to allow application developers to advertise feature support in general, but in particular backwards-incompatible protocol changes.

These events could then be pulled into an interface to give a quick overview of developer buy-in for a particular feature. Developers could also automatically be notified of new updates so that they have an opportunity to advertise their support. Sybil attacks can be mitigated through WoT. Relay developers can participate in this as well by creating application listings with no kind handlers.

@fiatjaf @pablof7z @jb55 @vitorpamplona @v0l

[alltheseas]

To add color and motivation, here are a dozen or so recorded nostr interoperability issues: https://github.com/nostrability/nostrability/issues

[mleku]

be like bitcoin, deprecate but leave old features supported

nostr needs to be like bitcoin if it's going to succeed

[sant0s12]

I think this is an interesting idea, however, adopting a protocol versioning scheme would be the way to go for the future, perhaps in addition to this.

I haven't figured out the details yet but I think having a protocol spec in addition to the NIPs would make sense. It would be like freezing the NIPs at a specific point in time. We could also take inspiration from the RISC-V spec, where they define a mandatory core and optional extensions.

For this to work, events would probably have to have some way to specify the "nostr version" that the client was targeting when creating it.

In any case, having a clear path to deprecate features is very much needed IMO. It is very unlikely to get things right on the first try and there should therefore be a way to fix past mistakes and develop the protocol further if there is enough support.

[fiatjaf]

Unfortunately life is such that there is no way to fix the problem and this is not the way either.

[mleku]

it is a new feature itself, sometimes that is a problem, i had this happen with a decoder cache i made a few weeks back, was more hassle than the problem it was aimed to solve

i think feature specs are a good idea but probably won't fix much in the way of problems for a long time, client developers are not as fastidious as relay developers and there's not many of us (like, for what reason i still can't surmise, nostrudel, next and production work with my relay but almost no other client even seems to want to connect without being prodded)

i think that this really should be an extension to nip-11 also