At first I thought it was reasonable that clients should merge the fields within metadata (kind:0) messages. For example, if user XYZ uses a client that supports `display_name`, and transmits that in a metadata message, then any client recieving that metadata message should include the `display_name` in the profile it keeps for user XYZ. If user XYZ switches to a new client that does not support the `display_name` field, and if that client sends out a metadata message, clients receiving that metadata should not erase the `display_name` field from their saved profiles.

But then I tried to imagine why this was useful. What is a client supposed to do with a field that it does not understand? It's not going to retransmit it to anyone else. It's just junk data serving no purpose as far as that client is concerned.

It seems to me that the problem you are trying to solve is a very different one. You have a particular configuration associated with your user identity. You want every client that you use to transmit that configuration whenever it sends out metadata. It seems to me that this is a configuration problem that you, as the user of a client, must solve; and for which the clients you use must provide affordances.

For example, more-speech sends out NIP-01 standard metadata every time it starts up. As I understand it, you are concerned that this "erases" configuration that other clients are depending upon. So more-speech (and presumably other clients) should allow you a few options.

1. Allow you to add fields to the metadata profile that it will reliably send when it transmits metadata messages.

2. Allow you to stop the transmission of metadata messages.

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

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

>Proposing a new nip: [NIP-24: Prevent Data Deletion in Replaceable Events](https://github.com/Giszmo/nips/blob/protectTheUnknown/24.md)