Thank you! Your reply is interesting but it deals only with measuring relay properties manually, not with relay performance ordering. Do you have any thoughts on that?
Other things to measure include ping, ttfb, and time to receive back a note I post.
The time to receive back a note is most useful for ranking aggregators like filter.nostr.wine.
But, I don't find lag to be too big an issue so the question I'm really interested in is if I want to connect to n relays, which will allow me to see notes from the broadest set of users with lowest latency? To measure that you'd have to connect these things for a while and see what the overlap is in terms of users. Users also post their relays I believe so that's another data source.
reply
"... the question I'm really interested in is if I want to connect to n relays, which will allow me to see notes from the broadest set of users with lowest latency?"
And that makes me again wonder: how are you going to decide whether relay_a has the broadest set of users with lowest latency than relay_b? Is there an algorithm to accomplish this task?
reply
Latency is per relay so I guess there'd be an exponential falloff. 100ms vs 200ms doesn't matter but 200ms to 300ms means the latency is starting to affect things. Maybe it can be statistically derived based on the population of relays you see. The bottom 10 or 20% for latency gets heavily penalized.
The other part of the score is log of unique users. Balance those two effects and I suppose you're good for ranking.
reply