Thread

We are beginning the development process for transmitting Nostr events in a peer-to-peer fashion, away from relays. This will start with Gift-wrapped DMs, Private Attachments, Private zaps, Private Text Notes, and Private Reactions; and will be the preferred transmission choice if both users are online, falling back to relays when they are not. Our Push Notification system already transmitted over 500,000 GiftWrapped Nostr events that relays will never see. With a full P2P this will get even better and will open the doors for voice and video calls directly inside Amethyst. Side-stepping relays won't be easy or quick. And I am sure we will get strong pushback from relay operators. But we will get there. And while this might start as an Amethyst feature, it will be a NIP and other clients will be able to join the privacy train. Nostr is just starting.

Replies (53)

I could see P2P transmission as being super neat for near-instant messaging. Not sure if it is a good idea for broadcasting notes to all followers, but there are definitively use cases where I would love that. Please do consider documenting it - even if not in the nips repo - for easier referencing when developing something based on this! ^^ IMO Nostr lives and dies from it's documentation. It is why there are so few Matrix clients, because the Matrix docs are a PITA...
↩ replying to someone
User 1 sends the event to User 2 via P2P instead of pushing through a relay. Then User 2 can send to any relay it wants for backup and to share with other clients the same user uses. Amethyst would just send it to your own write relays for backup for now. And we could have an option to turn that off for the privacy-conscious users. In that case, no event received via P2P ever leaves the phone.
↩ replying to Vitor Pamplona
Let me get this straight, will only private events be p2p? Because in your initial note you say that this movement starts with private events, which made me understand that in the future all events would be p2p. If only private p2p events and public notes continue to be transmitted via relays, at this point I support the idea. I believe that this way the scroll feed experience does not change.
↩ replying to npub1um8x...zp4e
Correct. Only private events will be P2P (because they are already encrypted in a P2P way). I just have way more private event types coming up, like legally-binding contracts:
GitHub
Add NIP-79: Digital Contracts, Covenants, and Agreements by xemuj Β· Pull Request #755 Β· nostr-protocol/nips
Introduces a new proposal (NIP-79) to standardize the representation of digital contracts, covenants, and agreements within the Nostr protocol. Thi...
↩ replying to jb55
You need servers for P2P signaling, yes. But that signaling doesn't need async queues. I also question the assumption that two users are not online. They might not start online, but as soon as one messages the other, both stay online for the length of the conversation. And if you do push notifications, like we do, you can get the other user online in seconds. If both are online they don't need relays at all.
All for Nostr privacy improvements. This will probably be one of those fundamental design choices which look obvious in hindsight and baffling that it wasn't included in the first or second drafts of the protocol. Then again this could fail spectacularly with users' phones filling up to the brim or connections almost always falling back to relays, with months and months of dev hours wasted for basically nothing. But what do I know, I'm just your friendly hoodlum in these cyphers. Interested to see how all this unwinds. View quoted note β†’
You must look at veilid. https://veilid.com/docs/overview/ "Veilid is an open-source, peer-to-peer, mobile-first, networked application framework. The framework is conceptually similar to IPFS and Tor, but faster and designed from the ground-up to provide all services over a privately routed network. The framework enables development of fully-distributed applications without a 'blockchain' or a 'transactional layer' at their base. The framework can be included as part of user-facing applications or run as a 'headless node' for power users who wish to help build the network."
View quoted note β†’ Nostr is about censorship resistance and at least for me, the most challenging mode of censorship resistance is censorship resistant broadcast. Avoiding meta data leak in encrypted transmission is a different problem to solve and nostr trying to solve the former would have to compromise on that to solve the latter. Therefore I believe Gift-wrapped DMs and "full P2P" is potentially harming nostr.
Hmm. How are you going to achieve this and stay interoperable with other clients? I assume the fallback transmission you mentioned? Also, would this be utilizing nostrdb, so that users essentially use their own relay and communicate to other's via their own local relays? Is there a gossip model being used? So many questions. Is there an external discussion that I can see and randomly yell into?
↩ replying to Derek Ross
Simple, if two users are using compatible P2P implementations, they can transfer their events via P2P, if not it goes through relays as usual. On a conversation via DMs for instance, I would assume the first DM comes in via relays and then moves to P2P when the person replies. The likelyhood of the two users being online is higher there. Then no additional DM goes through relays anymore, increasing privacy. Of course, each user can receive the message via P2P and still send to relays for backup, but that is the receving user's choice, not the sender.