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).

nostr:nevent1qvzqqqqqqypzqprpljlvcnpnw3pejvkkhrc3y6wvmd7vjuad0fg2ud3dky66gaxaqydhwumn8ghj7emvv4shxmmwv96x7u3wv3jhvtmjv4kxz7gqyq390g560s5wkcmlxxpwqqmup6pxq9vngyvfll344k9xzqhcu98l2t39lfg

Reply to this note

Please Login to reply.

Discussion

i thought everyone did this

although there is a better way which notedeck does: don't care about eose and just render things as they stream in. this is faster but not really best ux since it looks a bit crazy

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.

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.​

Wish I discovered it sooner. I'm gonna write something up about these "obvious" Nostr tricks that should actually be best practices

so a relay that has none of the events and serves up an eose, .. then the relays that do have them take longer but are in a race with 200ms timeout. this method would just force a blanket 200ms cap on all the relays.

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.