Conversation

Notices

1. Embed this notice
   jb55 (32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245@mostr.pub)'s status on Thursday, 21-Mar-2024 10:37:55 JST jb55

   • jack
   • fiatjaf
   • utxo
   • PABLOF7z
   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.
   
   @3bf0c63f 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.
   • Embed this notice
     fiatjaf (3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d@mostr.pub)'s status on Thursday, 21-Mar-2024 10:37:54 JST fiatjaf

     in reply to

     • jack
     • utxo
     • PABLOF7z
     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.
     Alex Gleason likes this.
   • Embed this notice
     Alex Gleason (alex@gleasonator.com)'s status on Thursday, 21-Mar-2024 10:44:18 JST Alex Gleason

     in reply to

     • jack
     • fiatjaf
     • utxo
     • PABLOF7z
     @3bf0c63fcb93463407af97a5e5ee64fa883d107ef9e558472c4eb9aaaefa459d @32e1827635450ebb3c5a7d12c1f8e7b2b514439ac10a67eef3d9fd9c5c68e245 @3d842afecd5e293f28b6627933704a3fb8ce153aa91d790ab11f6a752d44a42d @59cacbd83ad5c54ad91dacf51a49c06e0bef730ac0e7c235a6f6fa29b9230f02 @82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2 @e2ccf7cf20403f3f2a4a55b328f0de3be38558a7d5f33632fdaaefc726c1c8eb @fa984bd7dbb282f07e16e7ae87b26a2a7b9b90b7246a44771f0cf5ae58018f52 It should be the responsibility of the poster to ensure their message gets to all their followers. Not the responsibility of the viewer to find all the posts from people they follow.
     
     ActivityPub doesn't have this problem because it uses an inbox model. This makes sense because posters should be motivated to ensure their content reaches their followers.
     
     In Nostr when a user makes a post, we should enumerate their followers and find the best relay for each by NIP-05 or NIP-65. Then deliver the event to those relays. This is essentially what ActivityPub does.