Nostr Web Client

Yes in a world where everyone is running their own relay then the gossip model makes more sense.

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.

Reply to this note

Please Login to reply.

Discussion

PABLOF7z 2y ago

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.

MaxMoney21M⚡ 2y ago

Ideally the library would just have a "fetchEvent(id)" that gets whatever you want from wherever it is.

PABLOF7z 2y ago

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)

fiatjaf 2y ago

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.