The apps will pick them for you based upon your proximity (latency) to them. Ensuring you're not going half way across the globe.
Can of course be manually edited, but automated for most users.
Discussion
Ah okay, interesting. How does this deal with what Mike here calls clobbering?
How is this not simply solved by having Nostr clients refresh when they receive an updated kind 3? Nostr clients should keep an subscription open to the current user's relays to receive updated metadata (profile) and following list (kind 3) and relay list (kind 10002).
If any of those are received, simply update locally. Should not merge, should replace. Nostria keeps the original event itself, but if a client parse the content and store in a normalized structure, they should still remove/add when such an event is received.
Then in theory, following lists shouldn't be replaced by older ones, only if a device is offline, you edit your list and it publishes a new list when it comes online. That could also be solved by clients, by ensuring to first retrieve latest following list before publishing offline-generated events.
Right? Or am I not seeing the problem here? I understand that there has been issues, but the problem in my opinion, is clients, not the protocol. I truly believe another event kind is not the right solution to clients implementing existing protocol in a "problematic" manner.
(Yes, I know kind 3 has been renamed "contact list" and not following list, but I've always used that name).
Be interested to know as well. It's pretty clear when lists are replaced in this case, but it seems not all clients follow that. Didn't verify, just judging from use. Shouldn't have an issue with follows between the clients. Messages, etc. Yet, there is at times.
The issue for me is that it just takes a single client to implement in the spec messily to undo (potentially permanently) the carefully handling of every other client that has implemented it cleanly to that point. And given that people are vibe coding micro clients left and right, encountering messy implementations here and there should be seen as inevitable. And that just can't scale.
IMO replaceable events are at attempt at a single-copy-of-the-truth dynamic nested in a multiple-copies-of-the-truth architecture—and you just can't have your cake and eat it to in that regard. Tricky one.