Gossip client selects a pool of relays to used based on your follows.. this pool has an adjustable total size and has a 'coverage' score for your follows. It's unlikely that every user is on a unique relay. It will group the queries onto this set of relays for maximum coverage. You can specify the total following feed pool size and also number of relays per follow.
I understand that web clients have headaches using lots of websockets. This could be part of the issue? nostr:npub1dww6jgxykmkt7tqjqx985tg58dxlm7v83sa743578xa4j7zpe3hql6pdnf was saying that force closing a websocket doesn't work in a browser, is that correct?.. This and having poor cache/local db makes it harder to make a well performing web client but not impossible? My native gossip client rotates through a pool of only 15 sockets for 1000+ follows.
I think also maybe nip65 is missing additional fields that could make the calculations easier such as inbox/outbox/read/write/rank (the settings it has in its UI).
part of the problem is the relays don't respond to a "close" envelope by disconnecting either, that's also not in the spec, hoooeeee
there isn't actually a "close the socket" message in the protocol, at least no semantics are clear for this
the clients are so frickin dumb that if they keep asking for dumbshit the best way to respond with your relay is to literally just drop their messages and leave the socket open otherwise you have to deal with them dialing in again and again and again
Does strfry not close the websocket connection when it gets a close message? I'll have to look into this, if true, the middleware proxy I'm writing would be a good place to assist with a close I guess, or we can get this fixed in strfry. Gotta help these poor browsers out on stuff like this..
