Nostr Web Client

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?

verbiricha 1y ago

Relay lists should be distributed to as many relays as possible by clients. There are also some aggregators that crawl the network for those events and store them (purplepag.es, profiles.nos.social and nostr.band), if they don't have the relay list is likely because a user hasn't published any.

> Why do you think they should create one?

To make the outbox model work in practice we need people to have relay lists.

Reply to this note

Please Login to reply.

Discussion

fmar 1y ago

They should, but that doesn't mean they:

- write nip-65 to as much relays as possible

- have such relays as purplepag.es in their default relay list which gets used for nip-65 discovery.

Aggregators help a bit, but we should rely on them to make this work.

I still prefer that my nip-65 does not get overwritten without my explicit action on some stupid client.

For outbox model and for people you follow that you can't find a relay list for (BTW you should also check kind 3 and nip05 relay lists as a fallback) I would simply use a default list for the outbox calculation, but still wouldn't force a broadcast with a newer timestamp and that specific client chosen default list.

fmar 1y ago

*shouldn't