I've been doing it algorithmically, with a three-tries-you're-out-for-this-session method. Which means that it's slowish for about 5 minutes and then speeds up, as it puts those relays in timeout. I don't think I can remove that, as it also covers the common habit of having relays in your list that you can't actually write to, and cases where relays are down temporarily for maintenance. Do you have a cronjob to update the liveliness events, or how does it work?

I do like the idea of adding a bit more randomness to publishing events. Like having five randomly-selected relays from a curated/tested list added every time, as a client-option that the user can turn off.

And using the liveliness check to curate that list.

I moved off of greedy set cover btw 👩‍💻

Can I see the repo? Nostr.watch runs off nip-66 events. Its just that they aren't published to many relays, only: Relaypag.es Relay.Nostr.watch Monitorlizard.nostr1.com There's also undocumented events that can be used for uptime, kind 1066 cc @sandwich

Based on the benchmarks/report? What did you switch to?

I noticed I was missing notes especially when relays were down or rate limited me. so now each npub gets 3 relays, but we still use a relay score board we also do liveliness tests but not with nip66

They're all on my git.imwald.eu, I think, but it's just generic exponential back-off. I think my Jumble does it.

@Alex Gleason made an easy suggestion that fixes all these issues. After receiving the first EOSE from a relay, set a 200ms timeout for the other relays. Makes it incredibly fast and still gives the other relays a chance to get their notes in.

Good idea. I usually just render everything as soon as it returns, into the map, but that would also be very fast.

Are you talking about outbox? Which algo?

It wasn’t an algorithm, just a suggestion he made in a post. It works though. It’s fast and actually simplifies things too.

Appreciate this work. And glad to see my client work has paid off. Improvements coming.