I think there are lots of reasons. Here are a few…
- It’s complex to implement and requires a hardened ingester (sourcing notes from relays you didn’t select may be malicious)
- Performance and bandwidth penalties. Significant connection overhead increase.
- Clients who support NIP-65 often just copy kind 3 style 20 read/write relays in their list instead of the 2-4 the spec recommends
- Changes are still being made to NIP-65
> (sourcing notes from relays you didn’t select may be malicious)
not really; if a relay is evil it doesn't matter *how* you connect to it, whether you're social-engineered into it or if you connect through outbox, the client needs to be hardened regardless
> Performance and bandwidth penalties. Significant connection overhead increase.
Outbox model properly implemented can ultimately *save* bandwidth and resources for both individuals and infrastructure
> Changes are still being made to NIP-65
not really, we might be extending it, but there certainly are no breaking changes
How would one socially engineer a relay in to MY list? I use my own relay infrastructure. I agree that all implementations should be hardened (they should at least check signatures but many still don’t) but automatically connecting to relays vs adding them explicitly to a user signed list is very obviously not the same risk.
Could you point me to an efficient gossip implementation that actually saves bandwidth? I’ve monitored websocket data consumption on NDK clients and it is far worse than my own relay list.
Even if the current discussed changes aren’t breaking (debatable if we are changing where DMs should be delivered and how clients should store lists for their users and with what labels) they do require changes to implement correctly.
- Pablo is right in that it shouldn’t make a difference if the relay is malicious. nostr:npub18kzz4lkdtc5n729kvfunxuz287uvu9f64ywhjz43ra482t2y5sks0mx5sz The beauty of hashes and signatures is trust-minimized verification it provides. File chunking helps too when combined with them, to prevent delay attacks. 🔐
- Network overhead from opening and closing so many connections could become burdensome for clients, but I think it’s something we’ll eventually overcome. It’d be beautiful to bounce between such diverse sources of notes. 🗒️
- NIP-65 is a good start for encouraging clients read from the relays other users write to, rather than only reading from the relays the client is currently writing to.
NIP-65 isn’t perfect in every way, but that direction of reading from where others write is. 🛣️
When the concept is visualized, bouncing between all those connections as a user, it feels like the definition of decentralization… 🌐
I agree client implementations should be resilient against malicious relays but I don’t live in the “should” world I live in the real one and we were asked why clients haven’t implemented gossip yet.
The “it’s something we will overcome” is the only answer I’ve ever gotten about connection overhead. I don’t think it’s an issue that can be solved with faith.
We can't address these problems if we haven't taken first steps toward making them problems. They will always be theoretical and we won't feel the pain or have concrete solutions. Development is incremental.
Completely agree.
Relay traversal is an art and we can only explore it by taking the first steps, not by sitting and theorizing what it would feel like.
I didn’t ever suggest that we shouldn’t pursue solutions…
Jack asked why clients haven’t implemented gossip and I gave my opinion on the current state.
The connection overhead issue isn’t theoretical it’s observable today with a fairly small network and total number of relays. The problem doesn’t improve with scale, it gets worse.
Exactly… people gloss over the details and jump to take sides so fast. I said it was burdensome to open and close many connections, and agree that isn’t theoretical. Although hopefully we can overcome it someday (soon).
Sure, but you are comparing that problem with the unworkable status quo of "just use these three relays and you'll be ok"
If we presuppose that that's not the end-state of nostr then we need to compare the problem of opening more connections (outbox-model) with the problem of NOT finding the events you are looking (non-outbox-model)
Missing events is a far worse UX than a potentially slightly worse bandwidth usage.
This is the compromise bitcoin made; it's not the most efficient system, it's not trying to be. It's just trying to survive.
“Missing events is a far worse UX than a slightly worse bandwidth usage.”
100%
you wouldn't download an event
Opening and closing many websocket connections rapidly is more computationally costly than normal, but you’re right in that it’d be the same amount of data/total number of notes across the #nostr network.
good night 🌉
There is a lot more middle ground than you’re suggesting. It’s not a binary choice of 3 relays or automatically connect to any relay your follows tell you to.
I couldn’t figure out how the latter would scale a year ago and when I asked naively then I was met with the same talking points. I guess we are still in the same place.
The concept is much broader than NIP-65…
It’s either:
-Read where you write
Or
-Read where the post author writes
There are many nuanced variations & paths to reaching one or the other… but those are the 2 main paradigms I see.
There may be lessons we can learn from libp2p and other P2P networks. I’m busy with GitNestr right now but afterwards I’ll start experimenting.
If anything, hardware and internet speed will eventually evolve to support it, on a long enough time horizon. :-)
nostr:note1ypm4g4vzhkyf6umdj2nklqxlvs4jyv3f55th5kzk2k8ac23633hsmm5wvv
Another aspect of this is that we have to keep in mind that given the current "publish your events widely, request events widely" duplication of read/write is far more demanding than necessary.
You read to the 10 relays you've configured in your client and you fetch the same event from 7, or 10, of them.
Clients being smarter about where to read/write yields end up downloading the same events from far less relays and less resources requirement.
Do any clients try multiple relays in serial? Seems like everyone makes requests in parallel. But relays are usually pretty fast to reply, so if you chunked your relay set and requested from 3 relays at a time rather than all 10 you could get decent results with far less resource usage.
Exactly what I’ve been thinking too… off-the-top optimization^
I think the problem is the SSL setup/teardown, not the parallelism. But I haven't run performance tests, my research comes entirely from models, and my models predict... global warming and mobile phone warming
Yeah, I just think if some requests were serialized you might not have to open as many connections.
Gossip client has settings for "Require approval before connecting to relay" and "Require approval before AUTHing to relay", and you can approve just once, or you can save that approval for every time. You can also go to the relay page and change your mind.
Love these settings - well thought out. I’d like to see more of this.
Gossip has the best relay management for Twitter style feeds. Running it, you can prove to yourself that it can work.
Answer about connection overhead: I always agreed that this was a problem, but I've always said the solution: Don't do it on clients that can't handle it. Point them at client-proxies that handle it for them. We need servers that act as clients on behalf of phones, since phones can't handle the overhead of managing 50-odd SSL connections that potentially close and open often. This is still fully decentralized, scales, doesn't require copying events to hundreds of relays where they don't need to be, etc. It still is the "gossip model" or "outbox model" using NIP-65. It's not the *only* architecture to address this, but it seems the most natural to me.
Sorry that’s lame, trusting middle-men proxies is no different than trusting mega relays. Haha love you though for trying. We’ll figure out that raw outbox model on clients one-day!
> - Network overhead from opening and closing so many connections could become burdensome for clients, but I think it’s something we’ll eventually overcome. It’d be beautiful to bounce between such diverse sources of notes. 🗒️
100%
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.
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.
Just use rust shared library for crypto 😜
“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
🙏🙏🌞🏋️
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.
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.
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.”
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.
Spam is not a problem as you only query other users relay for their content specifically, not all notes.
(And only people you follow)
Yeah exactly… using gossip for requesting missing notes using the hash of the missing note is the way.
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 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
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 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.
Outbox model + Negentropy in the client = Incredible syncing — described above👆
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).
🤙🤙🤟🤟
I didn't mean to downplay the challenges, and I don't even think outbox/gossip model is the only solution or the best (although I can't think of anything better at this point). All I did was to complain about the current state of things and wish they were better.
Thank you for confirming that network overhead is not an issue.
Don’t make me write mean notes on your refrigerator. Let’s see how we do with at least 100 relays before we start celebrating.
MALICIOUS RELAYS?: I'd like to hear more about these "malicious" relays. Aren't clients hardened against badly behaving relays? If people want to hide their IP address there are means to do that (VPN, Tor). Anyhow, I implemented user-approval for the paranoid so each connection/auth is manually approved (once or always, and modifiyable later). Also gossip has always let users set rank=0 to disable a relay they don't want to use.
Connections are cheap except for SSL. SSL setup/teardown has a cost. If the same number of the same events come from one connection or 10 connections, the 10 connects is more expensive because of 10x SSL.
The gossip model is a major rework, I'm not suprised that it takes time. And I think your work on performance and efficiency is excellent, I designed chorus relay with some of the same ideas that nostrdb uses. I really want to see how fast Damus can go under the gossip model. I expect it will turn out to be highly performant once it's coded efficiently, and all the fear about too many connections will be proven wrong. OTOH if it goes the other way, then we have a very big problem on our hands. But without hard evidence we can yell at each other and never know which way we ought to all be going.
At the same time, I keep finding fundamental bugs in gossip which mean notes are not showing up, even this late in the game. Nostr protocol is designed to be simple, but is suprisingly hard to get right.
I like this layered, hybrid approach — that way there’s layers of redundancy and no one’s valuable work will be wasted: nostr:note13zznfktj20n7pdt62v0ttn3f6dn4q4ds90stfue0qqgwjymlkt4se83hfl 
Forgive me if this is stupid
'Unpaid relays that have recently successfully accepted a note' could be a useful list for a client to choose from, in a way that favors the least commonly used relay among them, to increase decentralization.
