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.

Reply to this note

Please Login to reply.

Discussion

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.

point is you likely could try a few other random relays and they would have the info to find alexs new relay, you are less likely to try randoms and find alex again without it, a dht helps with scaling too its not just for this

another solution is you store your relays on a file at your domain for nip5, relays could delete your kind0 linking to the domain tho

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.

The guy above was saying that relays would censor these messages, as if that was a problem with the gossip model itself.

I wasn't insinuating that it's a problem with the gossip model. If you read my comment, I said that I don't understand the model and how it solves this problem.