SyncThing is a free software alternative, but I wouldn't say that it is usable (yet) for the average user.
Syncthing is simply not designed for the mainstream. Resilio is. If Syncthing devs can fix that, I'll gladly start using it over Resilio with my non-technical friends.
(There's also a closed-source iOS app called fsync(), but I found it too slow/unstable to use.)
Previously on HN: https://news.ycombinator.com/item?id=14649727
https://github.com/warner/magic-wormhole/blob/master/src/wor...
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.
Three examples of this, implemented and working:
- https://www.sharedrop.io/ - https://www.justbeamit.com/ - https://file.pizza/
Ongoing work is happening, for example by the webtorrent folks, to remove this constraint.
Do these services also act as connectors in case of double NAT?
Would that meet the requirements without being a "central" service?
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.
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.
(Serious question - I've not used it myself, and I'm intrigued at the process.)
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.
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?
Am I missing something?
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
- 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.
I think you're referring to this? Clever hack indeed. https://github.com/samyk/pwnat
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 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.
> 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.
instant.io works pretty well for me, it works on the bittorrent protocol, but over webrtc
Or run a local SFTP server with UPnP and avoid the extra complexity.
In terms of finding each other, the client could get its external IP, open up a UPnP port, and provide the user with a QR code or brief snippet to paste into a chat conversation, which the other user would feed to their client to initiate the file transfer.
You could do this commercially by providing an external website with which the clients could communicate out of band to set up their transfers (for free), and (for pay) optionally provide a cloud sync service (which would help person A "pre-send" a big file transfer until person B was available to receive it).
While some of this is available today, you're right, I don't think there are accessible clients. ICQ, AIM and IRC used to be the solution, as they all did P2P file transfer. But now everything is on the web, so everything sucks.
Even if both parties are behind a firewall that won't respect UPnP, there's UDP hole punching which should usually work. Mozilla would just need to host a server to handle the port number handoffs.
I imagine this would handle 90% of the use cases. The rest would use traditional 3rd party hosting, IM transfers, email, etc.
I don't disagree with you but I kind of expected a note as to why this wasn't a solution in this context.
I think a solution to this problem that wasn't tethered would be something like in an IPV6 world where everyone has an IP address, if I could just put in your address, send you a file, and as long as our computers were on/connected to the world wide web, it'd get to you.
Aside I have recently noticed visits to ecommerce sites sit near permanently on top of my Firefox history than other sites, is Firefox doing deals with Amazon and others, and has this been been disclosed?
Doesn't work in safari though (haven't tested ie) so maybe it is not general enough for your use case.
The problem is that there are none with enough of a user base to have a network effect, and users hate installing new apps.
It's 2017 and it's still hard and somewhat dangerous to install apps.
It seems that bitorrent protocols are pretty close, but I don't think there is a seamless client that allows for "magical" point to point transactions.