Oddbean new post about login | logout Wait, this is a discussion about implementing a gossip protocol that adds discovered relays to your nostr client. There are people that aren't happy that public relays have blocked them as spammers. Plus, people aren't adding the spammers private relays to their clients so their spam is effectively blocked, unless you intentionally add their private relay to your client. Then you can see their spam. They call this censorship. So their solution is to implement a gossip protocol that discovers new relays and automatically adds them to everyone's clients to force people to see their spam, which you'll have to block by adding the spam relays to blocklists on your client. Their arguing that it's important that you read what they have to say, even if you haven't subscribed to their relay. They certainly seem to think they are important people. So, should nostr keep the current method where you subscribe to the relays that relay the notes that you're interested in, or change to a system where you get random relays pushed to you by a gossip protocol and you have to block what you don't like?
I think this is where @jb55 was getting confused. I’m not suggesting the outbox model that adds relays to your list of relays… your list of relays remain static. I’m saying to only leverage the outbox model when there are missing notes your list of relays don’t have, that way you are reaching out to the potentially evil relays with a note hash — if the note matching that hash isn’t delivered, then the evil relay can’t do anything but get your IP. This is more of a hybrid approach… Read from relays you write to —> clients can store data like relays and sync missing notes with a secondary list of relays using negentropy (snort coded negentropy in typescript already) —> gossip model for fetching missing notes if the first two methods fail. This seems like a solid plan/layers of redundancy for discovering missing notes… Thoughts? @Mike Dilger @jb55 @fiatjaf
That only works for known unknowns. It doesn't work for unknown unknowns. How can you know if you are missing a note you didn't even know about?
True! Outbox model works better for known unknowns. Unknown unknowns become harder, but if you request a list of notes signed by a given npub and verify the sig of each then that’s still a parameter you can use to avoid being spammed by the malicious relay. You can at least retrieve tons of notes from everyone you follow that you might not have seen otherwise, like the hello world experiment from @fiatjaf If the relay model and Negentropy in the client, you could even send the list of note hashes you have for that npub so the relay would intelligently respond with only the notes you’re missing, completing their profile.
REQ filters are not ideal, and negentropy-style syncing might be more efficient in some contexts. But REQ filters do pretty good. I can get all your notes over a time period, and if new notes flow in during that same time period (belatedly) I generally will miss them. But with some time overlap, hopefully I won't miss any notes that were put there in a timely fashion, which the outbox model generally will do.
Hhhmm, I'm going to go have a think about a way to exploit this model. Oh the other hand, is note retrieval across relays a problem serious enough to warrant additional automated discovery of relays? A new user with a fresh client is going to have way more trouble than a long time user with a well curated list of relays. How often does a long time user have problems retrieving notes? I'm not a fan of relays that bridge nostr to mastodon. I don't ever want mastodon posts filling my feed. What happens when the note that can't be retrieved wasn't actually a nostr note, but a bot created cross post from mastodon that I don't actually want to see, by not including bridge relays in my client? Will that note be forced upon me?
Hello Phill from Marketing. There are several misunderstandings here. First, the term "gossip" in this discussion comes from the name of my nostr client, the "gossip" client, which I named inadvertently in collission with a term of art that I was unaware of. We are not talking about a gossip protocol. Also, relays don't relay notes around (at least, not within the nostr protocol they don't). The gossip client, from day 1, tried to figure out where you post your notes to (if you were followed). Then it would go to that relay to get your notes, since the user of the gossip client was trying to follow you. The idea is simple: follow people. Let the software figure out where. That was later named the "gossip model" because of the name of my client. If I posted to chorus.mikedilger.com, nobody using damus would ever see that note because nobody using damus types in that obscure relay. But under the NIP-65 scheme, clients that implement the outbox model (a subset of the gossip model) would look up my relay list, find out that I post on chorus.mikedilger.com, and get my notes from there. Only my notes, mind you. No reason to get spammers notes (unless the spammer was followed).