Hacker News Reader

Comment by AndrewDucker | Hacker News Reader

You're at a computer.

You need to connect to another computer.

First you need to know a route to that computer. If it has an externally reachable IP address and you know that, then great. If it has an externally reachable IP address and a DNS entry and you know _that_, then also great.

If you don't know the IP address or domain name of the other computer then you'll have to do some kind of lookup/exchange to find it. That means some kind of centralised service to provide the lookup functionality.

If the other computer doesn't even has an externally reachable IP address then a central service is going to have to act as a connection point which you can both connect to (or provide some other method of helping the two of you connect).

I'm not aware of any entirely decentralised system which would allow two computers which are behind NAT to find and then talk to each other. Or any obvious design which would work there.

View on HN

WebRTC solves all the issues you're mentioning, and is available in Chrome and Firefox (in some for in Edge, and soon in Safari).

Three examples of this, implemented and working:

- https://www.sharedrop.io/ - https://www.justbeamit.com/ - https://file.pizza/

So, three systems which all require a central service?

Those services are for the initial peer discovery and SDP exchange, which can be done by other means (using any other side-channel).

Ongoing work is happening, for example by the webtorrent folks, to remove this constraint.

Yeah, it's initial peer discovery and connection setup (if behind NAT) I'm talking about. Once you've found the other PC and got a connection set up then all is well ;-)

Do these services also act as connectors in case of double NAT?

STUN allows all sorts of hole-punching for cases where both peers are behind NATs. For cases where the hole-punching doesn't work (a user behind two NATs might be one case), you can use TURN which is a dumb UDP or TCP relay.

They certainly can, I don't know if they do in practice. It always work for me, so I haven't investigated too much.

Which is a step backwards compared to bittorrent, since that can also provide decentralized hole punching, bootstrapping and peer discovery and not just the bulk data transfer. Plus being implemented at the TCP/UDP level allows more fine-grained control over the data flow, making it more friendly towards the network.

They're also needed for the actual javascript code that runs everything.

What about something like Tor. You can run a hidden service to get an onion address that any Tor client can access.

Would that meet the requirements without being a "central" service?

If privacy isn't your primary concern, and this is absolutely not private, you can also just use a redirection service and access .onion domains without installing Tor.

Just take any .onion domain and append it with .to and it should work. examplelettersblah.onion becomes examplelettersblah.onion.to and that works without needing to muck about with Tor.

This would be a horrible idea if you're concerned with privacy/anonymity. But, it'd make it easy for people to download your shared files.

That's exactly how Onionshare works. https://onionshare.org/

Never seen that before. But running a hidden service on Tor is absurdly easy, then you just shove a file server through whatever port Tor is forwarding.

I'm not aware of any entirely decentralised system which would allow two computers which are behind NAT to find and then talk to each other. Or any obvious design which would work there.

then you're clearly not the person we should be asking to build this kind of thing are you? :-)

my proposal actually solves two important problems with peer-to-peer systems, and I barely have to write any new code to make it work! the solution? i2p! it's an anonymous mix network, much like Tor, but completely decentralized. using an intermediary dex mix network fixes the nat issue and prevents you from leaking your IP address to other peers.

https://geti2p.net/en/comparison/tor

Assume I'm at my computer with i2p installed. How do I find your computer?

(Serious question - I've not used it myself, and I'm intrigued at the process.)

https://geti2p.net/en/about/intro

endpoints are identified by their public key hash. each endpoint maintains a set of anonymized routes. this routing information is stored in a Distributed Hash Table (DHT). if you want to connect to another endpoint, you lookup the route for the public key hash, build an outbound route, and you're good.

more concretely, an ipfs transfer would work by using public key hashes in place of IP addresses to identify peers and a known set of endpoint keys for bootstrapping.

So all you need is the hash (sent to you by your friend over IM or email or postcard) and you're good to go?

I like it.

Now, is it available today in a form (as the OP put it) which "A person whose computer knowledge extends to using facebook" can use?

if they have the ability to install software, they can use i2p

https://geti2p.net/en/download

Odd. I looked at the description on the main page, and it lists eDonkey, BitTorrent, and Gnutella, but not any kind of direct file transfer.

Am I missing something?

yes.

1. click bit torrent 2. click create torrent 3. type the path to your file 4. share magnet link

magnet:?xt=urn:btih:d0da0a2cac2bb3fd7ba6548edef12a24122ef481&tr=http://diftracker.i2p/announce.php

Does the magnet link work without DifTracker? Because that's still a centralized system.

yes, the tracker is optional. the built in torrent client supports BEP 5.

http://www.bittorrent.org/beps/bep_0005.html

Two thoughts:

- IPv6 kind of helps here, at least if we hope that no NAT standard ever makes it into IPv6. Crossing my fingers.

- There does exist at least one NAT hole-punching technique that can traverse two NATs with no central server using ICMP-based holepunching and UDP. Obviously, like all hole punching techniques, it only works on certain kinds of NATs, and firewalls can kill it.

> There does exist at least one NAT hole-punching technique that can traverse two NATs with no central server using ICMP-based holepunching and UDP. Obviously, like all hole punching techniques, it only works on certain kinds of NATs, and firewalls can kill it.

I think you're referring to this? Clever hack indeed. https://github.com/samyk/pwnat

IPv6 doesn't help in corporate environments, where it's often firewalled harder than IPv4.

The fact that it doesn't support NAT is seen as a risk in such environments ( which rightly or wrongly consider it as a second level of firewalling ). Some deployments that I've seen use only site-scoped with no globally-routed prefixes. Everything Internetty has to go over IPv4, which makes the Security team's job easier; drop all IPv6 at the DMZ and drop all non-NAT IPv4.

> I'm not aware of any entirely decentralised system which would allow two computers which are behind NAT to find and then talk to each other. Or any obvious design which would work there.

I think the GNUnet has some stuff in it which can even work across different protocols, e.g. hopping across TCP/IP over Ethernet to Bluetooth to packet radio. It has some neat stuff where, as I recall, it probes out a random path, then tries to get at its intended destination, remembering successful attempts. It definitely sounds cool, but it's not currently in an end-user-usable state.

Regarding this bit:

> I'm not aware of any entirely decentralised system [...]

What's the user value of having something entirely decentralized? I see the value in making sure the actual file transfer doesn't go through the central rendezvous. But I don't understand what's gained by eliminating the use of a little help setting up the connection.

The lack of a centralized entity collecting metadata. Who is sending files, when and how often.

The ISPs can do that, and they're pretty centralized.

Reply on news.ycombinator.com