At first I thought that advertizing supported NIPS was a good idea, and that even advertizing informally named features could be useful. However, this sentence gave me pause:

"Switching from a client that supports feature X to one that does not, should not trigger an update of the feature list except with the user's explicit approval."

How is the new client, which does not support feature X, supposed to know that the the client previously used by that user did support feature X? Moreover, even if the client could detect this, wouldn't it be a mistake for the new client to advertise a feature that it does not support?

Profiles are about users. Supported features are about clients. Mixing them together in the kind:0 metadata is likely to cause difficulties down the road. For example: as a client, I don't know what client user XYZ is using at any given moment. User XYZ's metadata might say that NIP-X is supported, but XYZ might not be using that client at the moment.

In other words, features don't stay with users. Users will move from one feature environment to another as they switch between clients. Therefore I don't think advertizing client features makes sense.

>From: Giszmo47 at 07/28/22 21:08:12 on wss://wlvs.space

>---------------

>Proposing a new nip: [NIP-23: "Supported Feature" Signaling](https://github.com/Giszmo/nips/blob/featureSignalling/23.md)