Nostr Web Client

Pablo is not right and I disagree with point 2 as well.

Having a fixed set of trusted relays is good for network performance and trust if your client isn’t hardened. You can just remove a bad relay if it’s malicious. In the gossip model you can’t and others can force your client to pull from any relay they desire.

Im not that worried about the network overhead if the gossip model, connections are pretty cheap, just a bit of state in the kernel. Maybe you would need some kind of LRU connection pool? I have yet to think about how to optimize this, but it’s not impossible.

nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6 continues to downplay the engineering challenges for the gossip model. Its easy to criticize us larger clients for not caring about decentralization, but its already very hard to make a performant client on mobile, and now we have to make sure our app still works in the presence of way more connections and potentially faulty and slow micro relays.

I’ve spent almost a year building an in-client relay just so this model doesn’t affect the performance and security of the app. I’m almost at the point where I can begin experimenting with this model only because of it. it’s a damn hard thing to switch to without a large amount of engineering, but we are getting there.

PABLOF7z 1y ago

my point is that a user can be told "oh, you can't see my notes, connect to my wss://evil-relay.com" -- I don't do any due diligence before manually adding a new relay to my list, I expect my client to not get buffer overflowed and leak my nsec or not be abused. That's the point I'm making wrt to the client needs to be hardened anyway.

Wrt automatic connecting to relays, users can blacklist relays to prevent connecting to a known bad relay and unfollow pubkeys that constantly send them to bad relays.

I agree that it's not trivial.

Reply to this note

Please Login to reply.

Discussion

All in 🥥🌴 1y ago

Just use rust shared library for crypto 😜

Colby Serpa 1y ago

“my point is that a user can be told "oh, you can't see my notes, connect to my wss://evil-relay.com" -- I don't do any due diligence before manually adding a new relay to my list, I expect my client to not get buffer overflowed and leak my nsec or not be abused. That's the point I'm making wrt to the client needs to be hardened anyway.” ✅

If you’re sending a note hash of a missing note to an unknown relay and the relay replies with anything but the note corresponding to the hash, then discard the data and disconnect.

What do you think about implementing the outbox model as a backup mechanism to the normal way of doing things?

This way it isn’t one or the other, it’s more like a fallback mechanism for if your set of relays are missing the note/if you can’t sync it to your Damus client-relay. Layers of redundancy…

nostr:note1djlkfuam8k03r6rryv5mma9jwzzs998juadayl0facg3wejcfh8s6hwc0f

Mike Dilger ☑️ 1y ago

Gossip does it like that actually. If a followed person doesn't have a relay list, and we have no data about what relays would be appropriate, then it reads from a user-configured set of READ relays. These may or may not be exactly equal to the user-configured set of INBOX relays published in kind-10002 NIP-65 event.

It has to do this because so many clients use centralized relays. So if I want to follow those people I have to add things like relay.damus.io as a personal READ relay or else I'll miss out on those people's events.

Phi Am I 1y ago

But, users can never blacklist 0-day bad relays. It would be a never ending, constantly growing blacklist because there's no upfront costs to setting up a malicious relay. Unlike lightning nodes, that require an investment in Bitcoin to open channels that you put at risk if you attempt anything malicious.

Every day, users would have to put up with the shit from the latest spam relays pushed to their clients, as well as updating the blacklist of the spam relays discovered yesterday.

Spammers will flood any gossip protocol with hundreds of spam relays each pushing tens of thousands of bot generated spam notes.

That is no way I'd ever use a client that kept adding random relays discovered by a gossip protocol. It would also make Nip-65 useless because so many other accounts would be full of gossip discovered spam relays.

Relays should operate by reputation. If I offer a no NSFW, no politics, no crypto filtered relay that had a reputation for filtering everything except cat photos and cooking recipes, shouldn't people only ever use this relay by choice, and not have it forced upon them unknowingly by a gossip protocol?

Just as relays flooded with Alex Jones Protein Shakes spam should never be pushed to anyone.

Colby Serpa 1y ago

This is non-sense FUD… you don’t just execute anything you download from random relays. First you hash the data and check if it matches the note hash you requested.

From one of my previous posts:

“If you’re sending a note hash of a missing note to an unknown relay and the relay replies with anything but the note corresponding to the hash, then discard the data and disconnect.”

Phi Am I 1y ago

Come on now buddy where did I say anything about execution of code? Stop the gaslighting.

Spam, is all I've ever said will be the problem with having relays pushed to clients by a gossip protocol.

I've never, ever said this is in anyway a security problem. So stop accusing me of saying that right now buddy.

Mazin 1y ago

Spam is not a problem as you only query other users relay for their content specifically, not all notes.

Mazin 1y ago

(And only people you follow)

Colby Serpa 1y ago

Yeah exactly… using gossip for requesting missing notes using the hash of the missing note is the way.

Phi Am I 1y ago

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?

Colby Serpa 1y ago

I think this is where nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s 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? nostr:npub1acg6thl5psv62405rljzkj8spesceyfz2c32udakc2ak0dmvfeyse9p35c nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

Mike Dilger ☑️ 1y ago

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?

Colby Serpa 1y ago

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 nostr:npub180cvv07tjdrrgpa0j7j7tmnyl2yr6yr7l8j4s3evf6u64th6gkwsyjh6w6

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.

Colby Serpa 1y ago

Outbox model + Negentropy in the client = Incredible syncing — described above👆

Mike Dilger ☑️ 1y ago

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.

Phi Am I 1y ago

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?

Mike Dilger ☑️ 1y ago

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).

Phi Am I 1y ago

Ok, that clears that up.