Vitor Pamplona @Vitor Pamplona - 1y
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.
utxo ⚡🫂 @utxo ⚡🫂 - 1y
Now it's just nost I guess
river @river - 1y
What are some of the possible drawbacks from side stepping relays?
CMHRZKSR⚡ @CMHRZKSR⚡ - 1y
content privacy or complete privacy?
liminal @liminal - 1y
Even less of an illusion for "global"
deleted @deleted - 1y
How exactly is it possible to remove the R ? Im confused.
Neo ⚡️ @neo - 1y
👀
I know thay haha, i mean like how exactly can nostr work peer 2 peer instead of with relays.
Its the first im hearing of this development.
Cameri @Cameri - 1y
are the energy and bandwidth requirements for this higher or lower? Are you planning on using negentropy for sync? Does that mean that my IP address would be available to any other user on Nostr?
deba2 - 1y
Are you building from scratch or reusing existing infra? E.g. Briar has solid implementation for passing messages over Bluetooth or local WiFi, Holepunch has interesting P2P streaming, SimpleX has good no-user-id concept, lightning has onion routing, Tor or I2P are the standard...
5be64 - 1y
You're pushing what now? Why is your service collecting and viewing all of this data something that's supposed to be better off that not letting it viewed in relays? You're also probably getting those because you default on gift wraps for DMs and it's causing user confusion so they don't even know.
738f6 - 1y
#Nostr 2.0 is incoming.... 👀🤙 nostr:nevent1qqsxes7e7r773kttrjjf3kw98pahz430jkn999jxuqsnw3qq7gprslcpz9mhxue69uhkummnw3ezuamfdejj7q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqznscs53
Humm.. I thought you would be happy with the privacy improvement... The push notification service just double wraps and transmits already signed giftwraps and other events that are coming from relays. It's the same old push service, but now extremely private.
The visibility of the IP address is what I am testing right now. We can always make it go through an internal Tor implementation, which I am also testing right now. But Tor won't work for voice and video calls later. But I think that use case is less sensitive of IP leakage since the user approves the call when receiving it. Lots to do yet.
What if both users are on Tor?
Bitkorns @Bitkorns - 1y
No strong push back from this relay. I'm only running one b/c this isn't already a thing. nostr:nevent1qqsxes7e7r773kttrjjf3kw98pahz430jkn999jxuqsnw3qq7gprslcpvemhxue69uhkv6tvw3jhytnwdaehgu3wwa5kuef0dec82c33wehx66ryxgurwurk0puxkdth89kkx7trvcerxctkxg6xuumrwa4nqerpxae8yenpvy6hwuf5dsuxsum9dpenjvrxw3k8v0mzwfhkzerrv9ehg0t5wf6k2q3qgcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqxpqqqqqqz5rkj52
In the way I see it, it's about the protocol to check if two people are online and then send the event over there, falling back to relays if it doesn't. The most basic version should work for this simplistic scenario. Then we can improve it over time.
I don't get how you're side stepping relays with these or why you think that it is good that you're able to see all of this data but relays aren't. Also any sort of social p2p shit doesn't scale. Been there done that. It's a pipedream. The only reason things work here at all is because of async mailboxes.
jeff @jeff - 1y
Interesting. Looking forward to see what you cook up. From the nostr readme: “it does not rely on P2P techniques, and therefore it works”
And the async mailboxes will be there when the app needs it. They just won't be used for private events to make sure folks can't track people (or at least can't touch the complete message set).
But it's okay for you to see all?
I am not seeing anything. It will be P2P.
He's literally bragging about seeing half a million private messages
It won't be, it will be a larp. You can learn from all the failed projects or not. Trying to push nostr to be p2p will be a wasted effort.
Those messages come from regular relays people are using and our service pulls from to deliver notifications. We double wrap them before shipping them out. I am very surprised you are having a hard time with this. This is not rocket science.
Well, you have your experience and your assumptions and I have my experience and my assumptions.
Do you have any sort of experience building p2p systems, especially in a privacy focused way? Do you realize the jeopardy you put your users in by deploying half baked ideas that won't even work? 1. How are you going to punch through NAT? 2. How are you going to keep that punch through method discoverable by every user? 3. How are you going to deal with users on different punch through methods/servers? 4. What's the best one out there currently? 5. Who is going to run the always online servers needed for punch through? 6. Are you expecting users to always connect to yet another server outside of relays, for the "sake of privacy"? 7. Why on earth would I want to connect directly to a random pubkey on nostr? I choose my relays. If you think I shouldn't trust them, why would I trust a random user? 8. How often do you actually expect that there's synchronous conversations? 9. If it breaks down at all and falls back often, the actual gains are miniscule.
Trying to push nostr to be p2p is retarded. nostr:nevent1qqsxtc94zyxntmpfn3f5lrtjnnu6xapqrddc9w5ztet27rk2dj0jy4qprpmhxue69uhhqatzd35kxtnjv4kxz7tfdenju6t0qgs9hejyd252x8q3kw6980ud4lymx3hlx2x3lgg6p7sz58nyv8m2nvgrqsqqqqqp0wr0v9
e6ce6 - 1y
What's the harm in trying? If it doesn't work, everyone is free to change the client. nostr:npub1gcxzte5zlkncx26j68ez60fzkvtkm9e0vrwdcvsjakxf9mu9qewqlfnj5z skin is at risk, if the work is as bad as you say, no one will use it anymore #amethyst
f5997 - 1y
Nostr Cash 😂 nostr:nevent1qqspm2pp3z9u8xuemy8e92552ps03au8v7duddqsw2jy0hhak05929spzamhxue69uhkzarvv9ejumn0wd68ytnvv9hxgtczypd7v3r24z33cydnk3fmlrd0exe5dlej3506zxs05q4puerp765mzqcyqqqqqqgucj4ht
Esharastr @Esharastr - 1y
Boobies! 😍🙌🏽
w3ird @w3ird - 1y
naw man. see? we need to move fast and break things. it's gonna be sick man. you'll see. just don't think about it.
daniele @dtonon - 1y
Fair questions. The #1 is the elephant in the room, I really cannot understand how this can work.
Русский бот @mikedilger - 1y
The general principle is there is a server that both parties rendesvouz through. It gets packets from both parties that connect to it. It can see in the packets the IP address, port, and other header junk needed for NAT in order to talk back to both parties. It sends that data to the parties themselves so they can talk directly to each other using those same NAT holes that were punched outbound to the server, while the server holds that open. This works everywhere including over CGNAT, double NAT, etc.
