I agree, this definitely needs some improvement.

Removing relays that you can’t connect to or that reject your events is more effective than simply adding more relays.

Where does the data come from? If it’s just scanning multiple relays, it might be difficult to recover historical events, since relays usually don’t store or return old replaceable events by default.

Glad to hear that 🫡

Got it. Clients should definitely provide some indicators to help users quickly understand whether a relay is working properly or not.

Most clients don't only send replies to the relays you configured. They also try to send them to the read relays used by the people you mention, so you usually don't need to add a huge number of relays for your replies to be seen. In fact, adding too many relays can make things worse. When someone replies to you, they may need to publish to all of your relays, and some clients (including Jumble) may ignore users with an excessive number of relays to avoid this problem. Adding too many relays can also hurt your own experience, because it increases the workload for your client. More relays mean more connections to maintain, more events to process, and more complexity overall. Relay management is definitely still a complicated part of Nostr, but having more relays isn't always better. The goal is to find a balance between decentralization and usability.

Has the move to kind 1111 become the consensus yet? Jumble is still using kind 1 replies for kind 1 notes. If the community has settled on switching to kind 1111, I’ll update it as soon as I can.

Jumble supports displaying both kind 1 replies and kind 1111 replies at the same time.

I’m not sure what an attacker gains by spreading an old 10044 event elsewhere. Clients should be fetching 10044 events from the user’s write relays / DM relays anyway. I don’t think putting it on-chain fundamentally solves the issue of senders not getting the latest update in time. It feels more like a different source of truth, querying relays versus querying the chain.

You’re right, this is indeed a problem. My current solution is relatively simple: when a user rotates their encryption key, they don’t immediately discard the old key. They keep it around for a period of time so they can still decrypt messages that were encrypted with the old key by senders who haven’t received the latest key announcement yet and are still encrypting messages with the old key.