Replying to Avatar jb55

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.

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.

Reply to this note

Please Login to reply.

Discussion

I like this layered, hybrid approach — that way there’s layers of redundancy and no one’s valuable work will be wasted: nostr:note13zznfktj20n7pdt62v0ttn3f6dn4q4ds90stfue0qqgwjymlkt4se83hfl