* makes it really hard to discover what mints people are using
(if it were it's own kind you can query the minds and see what other people are using instead of inspecting one-by-one kind:0s)
* kind:0 getting all these magic strings with different meanings is an anti-pattern
* you are all but guaranteed that some app will destroy this information accidentally
I hear you.
1) we don't want to do this for discovery. They should serve the same purpose as a lightning address in your profile does.
2) is that profile JSON precisely defined anywhere? I see a lot of mess in profiles and it seems to be ok?
3) yeah that's true but that seems to be a bigger issue. No app should just overwrite fields like that, right?
last point is key
i told nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 that deleting events for replacement is racy, and maybe people are starting to get the idea now... they should keep a history and prune them preferentially when looking to free up storage
just to explain how it's racy: it can happen that one moment my data set has a certain state, and because i send out a delete event, some relays will delete it, where some will just return the newest one and let you get the old one (this is common on some relays but not others)
there should be a stipulation in the replaceable events (both kinds) that they are preferably not actually deleted but multiple can be returned from a filter and then the client can filter through them and find the field they are looking for in a recent version
not deleting things and adding a "replaces" tag would fix all this problem altogether
it will take time for it to get rolled out but i think the number of times i have heard people talking about having their profile get nuked because it's a replaceable event i have definitely lost count
