Curious to hear: the a-tags have been useful for us as a way to consistently refer to a piece of music content even if the metadata evolves over the lifetime of a replaceable event -- this way the zaps are simple to attribute to the content. I see the concern though in your issue comment. What's the idea for this moving forward?
nm i think i understand what you mean now. The issue of replacing contact lists with reduced checkpoints is another problem which is more disruptive and difficult, the one im talking about here is a simpler problem to tackle.
This came up because people were starting to use a-tags as zap and like targets which seemed very wrong. I wrote up why here:
https://github.com/nostr-protocol/nips/pull/800#issuecomment-1741177812
Discussion
The way nostrdb works is that it keeps versions of replaceable events and aggregates sats and zaps across the entire note history, which allows it to know when a zap or like is targeting an older version. The main issue is that relates delete older versions so we’re trying to fix that at the protocol level (replaceable events change to versioned events ideally)
relays delete older versions*