Sorry fiatjaf I don't understand the model: doesn't the client need some information from a known relay, to get information about where to look for a particular user on a different (currently unknown) relay?
In that case, if the top 10 collude to ban Alex Jones, wouldn't they just ban every message related to him, including the ones telling people where to look for new content on the relay in Colombia?
Tell me how people are going to get information about Alex Jones's new relay so they can manually go to a hidden menu and type a URL there in your model.
I don't know, that's why I am asking how the gossip model solves it.
gossip means you can find things via other means, if the relays all had a dht with alexs new relay address you could just ask any relay
If the relays banned Alex wouldn't they ban the redirect to his new relay?
you can query the dht from another relay
So you would try random relays until you find it? The hypothetical is that you're only explicitly connected to the top 10 relays and they all ban someone.
kind1: “Follow Alex’s relay: wss://relay.infowars.com”, a widget appears that they can click to join.
what’s the problem?
Sir, can you remove the feature where the universe chat returns to the top each time I leave and re-enter it. It’s very annoying 😄
Universe channel*
I think clients should have a gossip model (I call this autopilot) and a manual mode. I prefer manual mode but autopilot would be better for most people.
well actually autopilot in damus is mostly about selecting relay sets automatically based on your friends and performance of said relays, which is slightly different than gossip model but heads in that direction.
over time you’d accumulate a lot of followed relays?
Yes in a world where everyone is running their own relay then the gossip model makes more sense.
Hey Bill, where’s the best place to learn about this system and relays? Need to read. 😉 thx
hmm now that I think about it it wouldn’t be hard to incrementally move to the gossip model in damus. I could calculate a subset of the fastest relays to query based on a thread event author and the relays they have configured. I would still be concerned about missing events but maybe it would be fine.
Might be better for people with huge relay lists? I still feel like this is a premature optimization though. Relay pools are dumb but simple. I would have to see if the gains are worth it for the complexity.
imo, all this complexity doesn’t belong in the client codebase; apps should focus on UX, not implementing event-fetching algorithms; this belongs in libraries that abstract away *how* a note should be fetched.
Ideally the library would just have a "fetchEvent(id)" that gets whatever you want from wherever it is.
We are, after all, all reimplementing the same logic over and over on each client; I’m writing NDK to use the gossip model and abstract this logic away from client developers
(Kinda like what fiatjaf was doing with easy-nostr)
You're focusing on the relay selection piece that #[0] has shown on that video as the "gossip model", but I think that's an implementation detail and an optimization. Much more important is the ability to know -- somehow -- that Alex Jones publishes on alexjonesrelay.com, connect to that and ask that for Alex Jones's notes only.
If the major relays all banned him, and those are the ones the majority of his followers were connected to, how would they receive that kind1 message to begin with?
Someone will post it to a public relay somewhere and it will get reposted to all the relays. I can’t imagine it being a problem that it could *never* be discovered.
