No idea which clients are, I only know I still see this workaround a lot in the logs, hey #[19] is Amethyst using NIP-65?
Discussion
I thought NIP65 was just a way to advertise relays to other users, not to use it as a way to setup your own... At least that's what the spec says. We just use the regular Contact list to keep the relay info.
Despite what the spec recommends, I understand it for both purposes, what's the reason for having it separately anyways?
Maybe I'm going too far and making this a meta discussion, but I see no reason for doing such separation, specially when kind 0 is neither a place to store this data
With that being said, I would like to just follow the consensus so I'm open to anything about this 🙂
I am good either way.
I am just starting to realize that this idea of general relays lists doesn't make any sense.
Home feed -> relays from follows
Global feed -> specific relay or relay set
Chats -> each has their own master relay
Private Messages -> shared relay between each pair of two users.
Notifications feed -> all relays in existence
User profile -> all relays in existence
Event info lookup -> all relays in existence
I totally agree with this list, but since you cannot connect to all relays in existence, I thought nip65 was for that but truth is that there is no real reason
A bit off topic, but I'm curious if clients implement the below, from NIP-65, obviating the need to manually add relays when following or replying to someone:
"Clients SHOULD write events that tag a person to at least some of that person's read relays. Explicitly, they SHOULD NOT expect that person will pick them up from their user's write relays. It SHOULD NOT be presumed that the user's write relays coincide with the read relays of the person being tagged.
Clients SHOULD presume that if their user has a pubkey in their ContactList (kind 3) that it is because they wish to see that author's feed-related events. But clients MAY presume otherwise."