Nostr Devs,
I chatted with
@The Bullish ₿itcoiner about this last night, as I have been testing out his new client
#Circl, but it bears notice of any client dev that supports lists of various kinds (relay lists, mute lists, bookmark lists, etc) in their client, or who plan to in the future.
NIP-51 states that these lists "can be public or private" and therefore may have plain text entries, or encrypted entries in the "content" field. It does not specify what list kinds may or may not have encrypted data. Therefore, your client should be able to handle encrypted data in almost any of them.
NIP-51 also says, "When new items are added to an existing list, clients SHOULD append them to the end of the list..." Appending only adds information, it does not remove any information that is already there. Adding an item to a list should never result in the loss of existing entries from that list, encrypted or otherwise.
If Nostr clients fail in this, Nostr interoperability and user experience suffers.
Here is what I would suggest:
Minimum: Your client should not overwrite encrypted data when adding a new entry to a list that has an encrypted payload in the "content" field. Leave that field there and as is if your client isn't set up to utilize it.
Better: At least decrypt and display the data to the user, so they don't think their whole mute list has been nuked because your client doesn't display the encrypted entries. And when your client is used to add new entries to the list, leave the encrypted data alone. Just add a new plain-text entry if you don't want to support adding encrypted entries to lists.
Best: Not only display the encrypted entries to the user, but indicate in the UI which entries are public and which are private. When the user wants to add a new entry, present them the option to add it as public or private.
There are certain lists this does not apply to, because their content has to be public for the list to function, such as kinds 10001, 10002, or 10050. However, the vast majority of other list types often do contain encrypted entries, especially since one of the most popular Nostr clients (Amethyst) is encrypting a lot of these lists by default.
The most common way I have personally had list entries get nuked lately is from clients that did know what to do with encrypted entries in the "content" field of my mute list, my favorite relays list, and my search relays list. Things like this are what make many people feel like Nostr is broken, when it's just that client devs aren't paying attention to NIP-51 when they implement lists.
#devstr #ndoc
