fmar on Nostr: There is a risk with that approach: if a client doesn't see some user's NIP-65 relay ...
There is a risk with that approach:
if a client doesn't see some user's NIP-65 relay list because it doesn't check those exact (maybe less popular) relays where user has published the list on (or it just had some issues connecting to the relays where that list exists),
and then goes ahead and publishes to some relays a new NIP-65 with their default relay list, it might cause a kind of overwrite it, which might not be the user's choice nor intention.
Nip-65 is a replaceable event, meaning a newer timestamp in ANY of the relay will be treated as a more up-to-date.
A lot of replacing/overwriting was happening with a lot of clients, so I would be careful with such a pro-active behavior.
Why do you think they should create one?
if a client doesn't see some user's NIP-65 relay list because it doesn't check those exact (maybe less popular) relays where user has published the list on (or it just had some issues connecting to the relays where that list exists),
and then goes ahead and publishes to some relays a new NIP-65 with their default relay list, it might cause a kind of overwrite it, which might not be the user's choice nor intention.
Nip-65 is a replaceable event, meaning a newer timestamp in ANY of the relay will be treated as a more up-to-date.
A lot of replacing/overwriting was happening with a lot of clients, so I would be careful with such a pro-active behavior.
Why do you think they should create one?