Nos stays subscribed to old relays on login

[mplorentz]

Describe the bug

When we log in a new user we look on relays for their contact list which includes their list of preferred relays. Simultaneously we open an "imporant events" subscription for things like the user's mute list, reports, delete requests, etc. Because we open this subscription before we have have downloaded the user's contact list it will use our list of allKnown relays rather than the user's preferred list. In rare cases this could lead to overwriting the user's contact or mute list in some scenarios.

[bryanmontz]

I'm looking into this, but I have some questions:

1. What is the desired state here? Are we wanting to unsubscribe from our "all known" relays once the user has logged in and re-subscribe only to the ones in the user's preferred list?
2. Is there a repeatable or predictable issue here, or is this a hunch about the list overwriting issue? If the latter, how will we measure success before shipping the changes?

[mplorentz]

@bryanmontz

1. Yes I think the way you worded it is correct, except that it's not when the user logs in that we need to do this, it's after they log in and we get their contact/relay list.
2. I haven't observed or written tests for a repeatable issue, but here's my nightmare scenario that I think I was imagining when I wrote this ticket:

• User sets up a Nostr account and is publishing to relays A, B, and C.
• Some time later, they remove relays A and B from their list.
• User logs into Nos
• Nos requests the user's contact list from its allKnown relay list which includes relays A and B but not C. Because of this it gets an old contact list. (Note: if this old contact list doesn't have relay C in it, we are also in big trouble. But that's a separate issue. So in this scenario it does)

In this state Nos won't request the logged in user's contact list from relay C to get the latest list until the app is relaunched or maybe in some other scenarios like if they opened their own profile page. If they follow someone or mutate their relay list in this app session they will overwrite the newer one that is on relay C.

So I guess it's less about staying subscribed or connected to allKnown relays, and more about making sure the critical subscriptions in CurrentUser.subscribe() get switched over to the user's latest relay list whenever we detect that their relay list has changed.

Maybe it's enough to just watch the user's relay list with a fetched results controller and call CurrentUser.subscribe() when it changes? In an ideal world we would also restart all relay subscriptions like the ones populating the home feed, but that seems much harder and much less critical. Most of our subscriptions get canceled and recreated anyway as the user moves around the app, paging through feeds or changing views.

Another option we've talked through in the past is keeping the user in the onboarding screens until we find their relay list. That's probably the Right Way™ and this ticket is more of a stopgap, so it's ok to compromise here I think.