I don't know why it took like 4 years to discover this advancement in Nostrology that's incredibly obvious. Make other relays in the pool race the fastest relay. No complex scoring system or relay manager needed. Just start a very short timeout (eg 200ms) after the first EOSE from any source to allow for other relays to get a word in. This prioritizes fast relays, as we should. It might even come down to latency of whichever relays are closest to you (a happy accident of this system that promotes geographical distribution).
Alex Gleason's avatar Alex Gleason
YOU CAN BUILD FAST NOSTR CLIENTS YOU CAN BUILD FAST NOSTR CLIENTS View quoted note →
View quoted note →

Replies (10)

This method is too complex for me. It's too easy to fall into performance traps. You know in theory how the code works but it's difficult to trace or debug. You can design a UI around it but the UI needs to break "is_loading" out into multiple steps, or use a queue. Plus you have to manage active REQs, potentially merging new queries into them. The dumb and easy way is to treat REQs like http requests that you cache and refetch in response to user actions (eg user scrolls back to the top after scrolling down).​
I avoid all the complexity by simply dumping all results into nostrdb. Then the entire app becomes a single relay subscription from the point view of the ui. A relay that loads instantly and offline.
I don't see why not. You just take the first relay response on a per-request basis; doesn't matter the transport. With Tor you might get less consistency as to which relays respond fastest.
Yes, this is what I did with Ditto and it's a very good system. You essentially build a relay into your client. You have to be committed to making it perfect though, or it will be a huge crux.​
i ran into this just this week. i had been taking the “display as the stream comes in” approach, but in one place i was waiting on all of the relays to return the current user’s event. felt so slow compared to the rest of the ui.