Oddbean

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? @Water Blower 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..

I think the whole thing is above and beyond the competence of nostr devs and they should just abandon it. Decentralized systems are hard. The apparent simplicity of the current nostr is what appeals to the peasants here. The next level of decentralized social network will come out of a different corner of the Internet and likely even be called something different entirely.

When you mention something like DHT, that means you're thinking of nostr as some kind of huge distributed database where data is guaranteed to be available for all time across all keys and easily searchable in a single query. Nostr isn't trying to be that. Saying nostr or gossip won't scale is like saying RSS won't scale, or IRC won't scale, or Usenet won't scale. Yet, they scaled just fine. Give up on the twitter style mega sharded database idea. Give up on easy centralized indexing/searching or thinking you'll connect to one firehose of data to rule them all.. it ain't happening. But you already know that.. I guess it's just I'm surprised at the expectations is all. If I wanted to find someone on nostr, I'd just connect to their relay and run a single query, I would know where to find them from their nip05 or from their last known relay list, or from any number of other out of band sources. EZ.