One thing I'm excited about for libp2p/tor is Arti. It seems like Arti, when it's ready, will make it much easier to build a fully functional and audited Tor client into a libp2p transport.
On Sun, Mar 20, 2022, 4:23 PM Jorropo <[email protected]> wrote: > Hey, I work for protocol labs (however not in the libp2p team) and I am a > go-libp2p contributor. > > > Thinking out loud: NAT traversal can use a rendezvous node, hidden > services are an intriguing option > > Yes there have been people who already thought that however, tor doesn't > need to do anything. > > I've worked on https://github.com/berty/go-libp2p-tor-transport once (PoC > leaks IPs with DNS requests, no audit, TLDR don't use it). > > > This first is to be able to advertise libp2p network in the directory, a > 16bit network ID would be sufficient(where about 16 networks could be > advertised). > > The second is to be able to send tor frames that unwrap to libp2p frames > once they reach a node advertising being part of a libp2p network or > networks(by way of using masking bits). I feel the second could be > accomplished with hidden service, but it feels more natural to want an RPC. > > If I understand correctly you want for tor clients to be able to dial > libp2p clients because something would advertise and relay libp2p endpoints > in tor's directory ? > > That sounds overly complicated and pretty much useless. I mean that looks > cool but if libp2p wants to use tor it can just use tor like anyone else > does (see my transport above), each libp2p node that wants to use tor just > run a tor client, connect to the tor network and register itself in the > directory, then advertise the tor hash in libp2p's DHT, to me this is a way > better solution because that doesn't make libp2p special, everything works > as they are supposed to and keep development efforts to a healthy low. > > > IPFS might still be inferior to Tahoe LAFS in real terms, especially due > to lacking erasure coding. > > IPFS isn't just a filesharing network, it's a content addressed network > (TL;DR no one owns files, it's a network where you query a hash and it > return you the content that has that hash). > IPFS is in philosophy way closer to bittorrent than Tahoe LAFS, Bittorent > is also a network where you query for hash and you get content that has > that hash and I don't belive anyone ever said that bittorent is bad because > you can't force people to remove your content (actually music and movie > lobby did but I don't think you would agree with them) and for me the same > apply to IPFS. > > > Now libp2p doing their own scheme for sending their stuff over Tor’s > existing streams makes sense. > > +1 > > > I’d expect libp2p to be a nightmare of downgrade attacks, given the > amount of badly rolled stuff they must still support, like their dangerous > key exchange SECIO built on the legacy curve sep256k1, but it’ll go deep > than that. > > It's really not, we have a fast deprecation cycle, unless you manually > choose to add support for it in your build it's not available anymore, any > software using libp2p right now use tls1.3, noise > <https://github.com/libp2p/specs/blob/master/noise/README.md> or QUIC's > layer (so I believe dtls). > > Le mar. 7 déc. 2021 à 19:33, Jeff Burdges <[email protected]> a écrit : > >> >> >> > On 7 Dec 2021, at 19:26, Jeff Burdges <[email protected]> wrote: >> > I advise against allowing any libp2p cruft into tor itself though. >> >> Among the many reasons. I’d expect libp2p to be a nightmare of downgrade >> attacks, given the amount of badly rolled stuff they must still support, >> like their dangerous key exchange SECIO built on the legacy curve sep256k1, >> but it’ll go deep than that. >> >> Jeff >> _______________________________________________ >> tor-dev mailing list >> [email protected] >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >> > _______________________________________________ > tor-dev mailing list > [email protected] > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev >
_______________________________________________ tor-dev mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
