Data loss: Relays page overwrites wrong relays

[franzaps]

1. I set my preferred relays in https://metadata.nostr.com – I verify 10002 events are properly sent to all relays
2. Load https://coracle.social/relays
3. Coracle does not properly read relays from my metadata:

• The UI shows very different relays to the ones I previously saved
• An inspection on the only common relay (wss://relay.damus.io) shows a REQ asking for kinds: [0, 2, 3, 10001, 10002] for 3 different authors but my pubkey is not there

4. Changes in Coracle (adding/leaving relay) trigger 10002 events which overwrite my relay settings
5. Back to https://metadata.nostr.com/ I refresh the page and see I lost my preferred relays. Fortunately I can restore latest versions from there

Coracle seems to correctly write but incorrectly read user relays from 10002 events.

Thanks for you work on it, I really like the client and want to keep using it.

[staab]

Thanks for the report, obviously this is a huge problem, and a difficult one to solve. I just double checked and Coracle does request kind 10002 events on page load. I also tried updating my relays in metadata.nostr.com and they showed up fine in Coracle. The only thing I can think of is that your relay selection is so different from the one Coracle is using to look for it that they don't intersect and it's not finding the relays.

Requests for this data are not optimally merged right now, so there might be multiple requests for relays, see if you can find the other REQ.

[franzaps]

Appreciate your response. It's true that the intersection was small, I think 1-2 common relays. Just to clarify: I purchased a nostr.wine subscription and I'm trying to only use that premium relay that is supposed to aggregate reads and blast writes.

Not everybody has relays in their NIP-05, but would this be a good way to bootstrap for those of us who do?

[staab]

You're right, nip05 would help a lot with this. I'll look at using it. It could also be an AUTH bug if you're focused mostly on nostr.wine. I'm hoping to re-work the fetching logic again at some point which will hopefully help with that problem.

[staab]

This will be much improved in the next release. I've opted to skip NIP 05 for now, since finding your handle requires having access to your kind 0, which is not likely to happen unless you already know which relays to use, or have an index which contains the data you want.