Replies (14)

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.
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
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
@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.
It wasn’t an algorithm, just a suggestion he made in a post. It works though. It’s fast and actually simplifies things too.