if you're getting 300 "didn't connect at all" you should also be getting 300 WebSocket errors in the console. it should be the most common error message. if your browser isn't letting you talk to remote WebSocket servers, you're going to have low visibility.
(using NRCheck i mean)
could you right click the page, click Inspect, select the Console tab, run a search and show me the errors you're getting there?
on my end, i'm only getting 2 relays that didn't connect at all and 67 that took so long to respond that the tool gave up.
your "didn't connect at all" number is VERY high though. that means your computer can't reach those relays.
that's a rare sight for me. can you send some notes that i can search?
are you sure they're only being transmitted to one relay?
somewhat tempted to set up a tracker on tigerville.no to store the metadata i need for https://nrcheck.tigerville.no, https://nosy.tigerville.no and other tools. i'm not finding the relays very reliable or consistent. you'll search them for the exact same thing and they respond with a slightly different list of results each time.
there's a bit of irony in setting up such a centralised data store just to get fast, reliable and complete data sets, because it goes to the core of why mesh networks are challenging.
somewhat tempted to set up a tracker on tigerville.no to store the metadata i need for https://nrcheck.tigerville.no, https://nosy.tigerville.no and other tools. i'm not finding the relays very reliable or consistent. you'll search them for the exact same thing and they respond with a slightly different list of results each time.
you mean filter.nostr.wine? i'm guessing it must be because it monitors that stuff over time, so even if relays reply inconsistently, it keeps collecting that over time. it's unfortunate that this is necessary. i don't quite understand why relays don't respond reliably to such queries.
the idea is that i'm writing my own tool at https://nosy.tigerville.no, and i want it to give accurate follows, so that's not helpful in this case
not sure how snort.social counts followers, because when i query 300+ relays for users who follow a particular npub, the numbers i get back vary a lot.
well, let me know if you can find it. it has one use case: marketing
your follows and your saved relays are kept in a NIP-02 record:
https://github.com/nostr-protocol/nips/blob/master/02.md
the NIP-02 document doesn't describe how relays are kept, but it's a quoted JSON string in the "content" field that decodes to:
{
"wss://domain1": {"read": true, "write": true},
"wss://domain2": {"read": true, "write": true},
...
}
your follows, meanwhile, are in the "tags" field like:
[
["p", "pubkey1"],
["p", "pubkey2"],
...
]
nope, that doesn't work, because if one follower is on 5 relays, he is counted once on each relay, so it will be 5 in the total. but i have changed the code to include followers. it was easier than i thought.
kind of tempted to make an animated visualisation of Nostr socal networks and events that looks a bit like this
you know, i would happily use *only* relays in my region and offload the big ones, but it would put me out of reach of a lot of users.
one thing i will make sure to do is add a Latency column to this tool as i did for https://nrcheck.tigerville.no so people can judge which relays perform the best for them (usually a local one)
the main centralisation driver is that so many clients default to a small handful of standard relays. hopefully, those who use this tool are looking for *other* relays to add than the usual suspects.
note: the relay list is based on what relays users have saved (to their NIP-02 contact list), not which relays they appeared on. a handful of my own followers and follows don't have such a list at all. some of those are from relay.mostr.pub - the Fediverse bridge - because it doesn't appear to provide that for its users (which is why they all appear to be following nobody). i've let the maintainer know about it, since i'm sure he's interested in having his bridge listed.