_______________________________________________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.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).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.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 ?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 optionYes 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.
> IPFS might still be inferior to Tahoe LAFS in real terms, especially due to lacking erasure coding.
> Now libp2p doing their own scheme for sending their stuff over Tor’s existing streams makes sense.+1It'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 or QUIC's layer (so I believe dtls).
> 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.Le mar. 7 déc. 2021 à 19:33, Jeff Burdges <burdges@xxxxxxxxxx> a écrit :
> On 7 Dec 2021, at 19:26, Jeff Burdges <burdges@xxxxxxxxxx> 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
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev