Replies (134)
peers in p2p are servers
from the lead dev of holepunch.to
X (formerly Twitter)
Mathias Buus 🕳🥊 (@mafintosh) on X
Distributed holepunching through the Hyperswarm DHT
there is distributed holepunching aka nat firewall traversal
other stuff
Yes, it uses a lot of techniques I'm well familiar with, techniques that don't really work anymore. Like STUN. Mobile networks especially, you're just gonna end up sending all that traffic through a turn relay (which is fine).
Traversal Using Relays around NAT - Wikipedia
WebRTC
TURN server | WebRTC
But it’s the difference between a distributed and decentralised network. Distributed is P2P and it has even more trade offs than decentralised networks.
There are no free lunches
Then we will navigate those trade-offs and let users choose what they prefer. :)
nostr is already distributed and not p2p except for relays
trade offs are being worked on, we also have more compute and network resoirces than ever
data is very cheap especially on local networks, the lunch is cheap
as p2p apps become popular incompatible shit 'networks' will face tremendous pressure to become proper networks
I wish. A majority of the world is on a mobile carriers network.. I just don't see how it would apply any pressure, can't even get people to use a desktop browser anymore.
I’m open to being convinced but what do we need this for? Is it just private DMs?
#brothelstr
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...
Yes, how?
then you either dont understand nostr or distributed
i am not going to bother with that silly article btw tho it likely agrees with me
Vocabulary.com
Distribute - Definition, Meaning & Synonyms
To distribute is to disperse widely, hand out, or spread around. While you're still snoozing, the paper boy is busy distributing the newspaper...
'To distribute is to disperse widely, hand out, or spread around'
how are nostr notes distributed? how can nostr notes be distributed? are nostr notes on a wide variety of servers? are nostr notes handed out widely to relays? can i put nostr notes on a usb stick and give them to a friend? can that friend send those notes from that usb stick to a relay? can 500 other relays download those notes from that relay? can 1million people download those notes from those relays?
how is nostr distributed?
many mobile networks work p2p, mobiles also have wifi, starlink lol
there will be nsa datacenter peers to use, its what american tax victims pay for
Hot take: a protocol centered around the internet is inherently more open than a protocol centered around relays on the Internet. One includes the other.
View quoted note →If it fails it goes back to relays. So, it shouldn't have any impact. It's just additional privacy when the user are able to connect to one another.
Relays are public and shouldn't involve with private things yes. I support this.
What if I use both Amethyst (mobile) and Primal (desktop)?
Primal will not be in sync with my private communications.
dYeah, it's not for public notes. The idea is to focus on private ones, which is generally just encrypted p2p anyway :)
This is why I think we can succeed. The relay infrastructure will always be there to be a fallback. The P2P stuff is an additional layer of privacy to be used when 2 phones are able to reliably connect with one another.
So, passing over Bluetooth and internal WIFI is very easy (which was my first test a few weeks ago). I just started doing some WebRTC tests and looking at some server alternatives and signaling needs. It works but I am very early in this whole adventure.
I looked at Rendez-vouz as well and I was wondering can't we just pass the signaling through our usual relays instead? Maybe we still need some type of STUN server to get the phone's IP and as long as two users can use different STUN servers, it could work.
What I want to avoid is replacing our replays with a different "relay". If we need to use a server to transfer some info we can just use our regular relays instead to avoid another dependency/attacking point.
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.
I think a simplex-like queue abstraction on top of nostr would be the best of both worlds
I have not found a reason to use Simplex if you are doing WebRTC. Instead of Nostr -> SimpleX -> WebRTC, you might as well just do Nostr -> WebRTC. It's one less point of attack.
Private DMs, Private DM Attachments, private Zaps, and private reactions on top of Voice and Video calls.
The point of simplex is the async queues which you can’t replace with p2p tech. Nostr is missing the ephemeral push-pull queue idea
Have you written out the architecture anywhere yet? Would love to dive in and understand
No, I am just testing things out for now. WebRtc seems to work, but I want to get rid of these servers they use for signaling and use giftWrapped msgs in Nostr for that.
I'm might have multiple layers. Bluetooth, WIFI for those physically close to one another and some version of WebRtc for the rest.
Interesting 🤔 well I look forward to more info
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.
I think I understand now. So I really don't see any problem for the relay operators, nor for the feed experience 🤷♂️
Looking forward to the new private events 🚀
Probably will at least create more confusion in the clients that already causes issues. What other clients are already planing this with yours?
Sounds like combining the best of both decentralized approaches, great take. I think Nostr should stay open to innovations like this.
I don’t know what this means but it sounds provocative
This nip is given me a boner
My bad got the quote wrong 😂
Love Amethyst 🫂💜👍🫡
would this make nostr client/s less data hungry?
Gossip model + clients as relays
View quoted note →> How do you decide which peers to sync with on Amethyst P2P? There are so many users.
It can be done, here's just an example:
It should be possible to generate an onion address keypair algorithmically from the recipient's Nostr keypair, in a manner that is reproducible on sender-side using only the public key. Roughly similar to how Bitcoin HD wallets (xprv/xpub) work.
There are probably some privacy footnotes with this method, but would give you 100% accurate peer discovery without an intermediary.
Just to be clear, none of this exists. It's only an example of how it could be done.
Is there any use case for using IPFS as data storage for Nostr?
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 →reminds me of Microsoft's Skype
"Nostr is just starting" --
@Vitor Pamplona @ ~Fall Equinox 2023
Listen closely if you didn't do already.
View quoted note →What's the niche of the vanilla SimpleX client for Nostronauts from your point of view? #asknostr
Yes I think using nostr relays to setup rendezvous is a great idea, with hole punching something like this
https://itnext.io/p2p-nat-traversal-how-to-punch-a-hole-9abc8ffa758e
What lower level protocol are you thinking of using? UDP messages? TCP with message framing added back? WebSockets? If we are starting a new protocol, can we go binary?
We will need to go binary for voice and video calls. But for the messages that are just simple nostr events, I am not sure if it makes sense since the event is already in text.🤔
Yeah baby!
I look forward to your progress.
How did Napster do it?
Is this similar to the way Napster/Limewire worked?
View quoted note →Wouldn’t ruin the “whole” point, I think it would be usecase specific, notes would always need relays, calling, and maybe even DMs don’t really need relays. Solutions to problems often have a way of sidestepping politics of ideas.
Is this comparable to something like holepunch?
quote tweets on primal sucks
Could you please elaborate on “the protocol to check” ?
With arti you can configure tor to work fine for video calls on a phone.
Can't believe what I'm reading 👀 This could be mindblowing 🤯
View quoted note →🤔🤔🤔🤔🤔
This is a big challenge, support. Nostr now allows anyone to see who you're talking to through your public key, even if you can't see what we're talking about. It's not nice to have a private chat party in a glass room in the square where everyone can see. Better protection of privacy would be a huge step forward.💜🫂
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."
Is this available in China? Push service against GFW…
Absolutely!
does anyone know they should save their data themselves ? This is the only point that bother me in this 😉
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.
Is there a thread that discusses this? Would love to be a fly on the wall for this 🧐
Async queues could fit nicely into relays. The queues are a really interesting solution in my opinion and I wonder where is that applicable in Bitcoin or Nostr space...
I agree async queues could just be implemented in Nostr but I don't see a need for async queues at the moment. But maybe I am missing something...
It enables ephemeral asynchronous notes without p2p
So, would your IP be shared with your peers?
That doesn't initially look too good for privacy.
Looking forward to learning more about this 'protocol'.
🫂
Yeah would have to be an extension
I understand. But I don't have a use for that yet. It's a nice to have in my bucket.
P2P is a must though. The whole point of p2p is to transfer private content without any servers involved.
You pretty much always need servers to holepunch connections at the very least. Not to mention its also pretty rare to have two clients online at the same time to establish p2p comms. Even in that case you may still need bridge servers.
Given these difficulties a temporary queue of messages would be much more reliable and just as private, if auth was required from the get go.
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.
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?
I think it’s fair to say amethyst is not going to be very compatible with other clients going forward. I highly doubt anyone would build around his centralized push server as a core protocol mechanism.
I am not going to use the push server for P2P. There is going to be no server. Thats the whole point.
Plizz no hard forks
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.
I doubt. I already have a small version working without a server.
Odds of two people being online at the same time, in a world where apps are background suspended constantly: almost zero.
I am not doing a sync between devices. I am just broadcasting the event directly to the users client.
Thanks.
Two peers behind nats need a server to coordinate/holepunch connections. This is pretty standard knowledge when building p2p stuff. What is this magic serverless tech you are using?
Establishing p2p connections is a very hard problem with many nat variations to get around.
The receiving user can send to the desktop if they want to. The choice is the receiver's not the sender's.
Usually yes, but not in a DM conversation. After the first messages, its more likely that both are online.
And we will need both online for voice and video calls anyway.. so..
Man I need someone to explain this to me like I’m 5
Yep, it is pretty standard. :)
Well, the experience I have says otherwise.
Lots to test yet. We will see if can get this to an interesting level.
🤷♂️ I guess time will tell. I don’t know anyone who keeps a social app open between messages. They depend on notifications for that.
And we already have push notifications if we need to wake them up again. But our tests suggest that people don't leave amethyst when waiting for a DM. They just move to the feed. Which is perfect for this.
Well I don’t wish your idea ill anyways. I’d be doing a disservice if I didn’t voice my concerns, but working code trumps theory. We will see.
As long as it doesn’t break compatibility with other clients (fallback).
It shouldnt break, just open a new way for exchanging events. But I still have lots to test.
I will likely be doing Bluetooh, WIFI and WebRTC implementations, so there will be 3 new ways to share the event. But one at a time.
всех распустить...
This is great Vitor! 👏👏👏👏👏
Wow,
respect!
This sounds amazing!
really looking forward to the future of #NOSTR
Means we can take over everything in communication with any possible device that has access to the inet.
Sounds like fun.
View quoted note →Bullish. Relays can be a point of failure. P2p is the way
interesting
Fair questions.
The #1 is the elephant in the room, I really cannot understand how this can work.
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.
unless the gateway restricts those holes to the server's IP address.
Yeah. So how can works the *serverveless* p2p envisioned by Vitor? I cannot grasp this.
If i could, there wouldn’t be plagues raging, and murders charged, Tony
How is that ass cancer to die of, gangster?
I can’t since we have been accused of murder.
Can’t work it.
Have a blood bath.
It doesn't
Got it.
🤷♂️ must be magic
Ok, this is what I am testing.. Dont take this as a final solution.
First: IPv6. On IPv4, you have to deal with NAT travel + firewall holepunch. With IPv6, the NAT stuff is gone. All you need is a simple STUN server to open the connection.
Second: We can use Nostr to signal people's IPv6+port to one another.
Once that is done, both sides start sendind UDP messages over IPv6 to each other. The first 2 messages should be rejected because of the firewall, but after that the door is open. We try this until we hear a package back.
Now, the beauty of Nostr is that somebody is always online. Which means other phones can behave as STUN servers to open people's firewals more easily.
The goal is to use network effects to avoid the need for central servers. Market participants can add their computers or phones to the pool by just replying the Nostr signaling requests.
It's like a STUN server as a DVM.
Lots to test, but that was the idea.
what if.. forget about STUN for a second, it isn't gonna work for most peers (esp mobile carrier networks). You could support ipv* by 'relays' running coturn and forcing the use of the turn server vs. stun would not expose IP info between the peers. Coturn has all the stun options, so if a peer was willing, they could opt in to the IP disclosure and achieve a true P2P connection.
multi hops could also be implemented, by using wireguard networks with relays being a 'hop' server.
GitHub
GitHub - coturn/coturn: coturn TURN server project
coturn TURN server project. Contribute to coturn/coturn development by creating an account on GitHub.
Yeah that's the easy way to do it. But I think we can do it without coturn. Most of what coturn implements is for the old nat stuff. There days everyone has an IPv6. Só it should be easier.
🤔
"These days everyone has an IPv6" - don't think that's the case at all. Most countries seem to be running at around 50-60% deployment, and that's only showing allocated IPv6 that doesn't mean configured and in use.
But it is a fallback for the p2p if everything else fails.
given how popular vpns are im not sure why anyone would want to connect p2p 🐻❄️🤔
cool idea, subscribed!
I have implemented the calling service in 0xchat, but using the traditional technical solution:
Relay signaling+WebRTC+STUN+TURN.
I’m looking forward to your experimental results. :)
Which servers are you using for stun and turn?
That seems different than what I have but if that is true let's hope we can help them finish the transition.
Google’s STUN and our own built STUN/TURN service, followed by support users to input their owned services, similar to the approach of Simplex
Let's hope you can. It's been in deployment for ~20 years!
Maybe you're mixing cellular and fixed line services. On cellular, the figures are likely higher but on fixed line they're also likely lower. Mobile users aren't, most the time, using a cellular connection though, they're using WiFi.
https://ipv6-test.com/stats/
