over time you’d accumulate a lot of followed relays?
Discussion
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.