I didn’t ever suggest that we shouldn’t pursue solutions…
Jack asked why clients haven’t implemented gossip and I gave my opinion on the current state.
The connection overhead issue isn’t theoretical it’s observable today with a fairly small network and total number of relays. The problem doesn’t improve with scale, it gets worse.
Exactly… people gloss over the details and jump to take sides so fast. I said it was burdensome to open and close many connections, and agree that isn’t theoretical. Although hopefully we can overcome it someday (soon).
Sure, but you are comparing that problem with the unworkable status quo of "just use these three relays and you'll be ok"
If we presuppose that that's not the end-state of nostr then we need to compare the problem of opening more connections (outbox-model) with the problem of NOT finding the events you are looking (non-outbox-model)
Missing events is a far worse UX than a potentially slightly worse bandwidth usage.
This is the compromise bitcoin made; it's not the most efficient system, it's not trying to be. It's just trying to survive.
“Missing events is a far worse UX than a slightly worse bandwidth usage.”
100%
you wouldn't download an event
Opening and closing many websocket connections rapidly is more computationally costly than normal, but you’re right in that it’d be the same amount of data/total number of notes across the #nostr network.
There is a lot more middle ground than you’re suggesting. It’s not a binary choice of 3 relays or automatically connect to any relay your follows tell you to.
I couldn’t figure out how the latter would scale a year ago and when I asked naively then I was met with the same talking points. I guess we are still in the same place.
The concept is much broader than NIP-65…
It’s either:
-Read where you write
Or
-Read where the post author writes
There are many nuanced variations & paths to reaching one or the other… but those are the 2 main paradigms I see.
