In my experience companies usually end up paying for a service that solves this problem for their employees. Yes really.
Anyway I would suggest using
https://magic-wormhole.readthedocs.io/en/latest/
or RustDesk. RustDesk has a nice GUI and file transfer has a really nice two pane file explorer view but that is obviously not great for transferring files to people you don't fully trust.
Yes, and tech folks too, but what about if you're not already connected friends? You don't want to invite your entire audience at a conference to send them slides.
You either need to already have a website and say "click on News and find the entry for today", have them type over some long URL with perfect accuracy, or use a link shortener to the same effect. It always requires having hosting, unless there exists file sharing services. That's the problem these things solve.
Also mind that there are size limits in most messengers on the order of a few hundred megabytes. You don't run into them that often, but whatcha gonna do when you do? A dedicated file sharing service that supports in the gigabytes range solves that situation as well.
https://github.com/schlagmichdoch/PairDrop
Other alternatives:
There are myriad options if you get a server of some kind. A webserver is even easier to get, and to share, than an FTP server.
That's not the challenge these projects attempt to meet.
Now that we’ve shifted our company’s focus to https://socket.dev, I’d love to open source Wormhole. I’m quite proud of the code - I’ve worked on P2P and file transfer systems for so so long that I think this might be some of the best code I’ve worked on.
It’s just a matter of finding the time, but I expect this will be open source eventually.
That device ID you have to send to someone is not nominally private; it is in fact explicitly the public key of a key pair. If you use the public discovery servers (which is the default), that key is sent there so people who'd want to connect to you can look up your IP address with it.
https://docs.syncthing.net/users/security.html#global-discov...
https://docs.syncthing.net/users/faq.html#should-i-keep-my-d...
> Should I keep my device IDs secret?
> No. The IDs are not sensitive. Given a device ID it’s possible to find the IP address for that device, if global discovery is enabled on it. Knowing the device ID doesn’t help you actually establish a connection to that device or get a list of files, etc.
> For a connection to be established, both devices need to know about the other’s device ID. It’s not possible (in practice) to forge a device ID. (To forge a device ID you need to create a TLS certificate with that specific SHA-256 hash. If you can do that, you can spoof any TLS certificate. The world is your oyster!)
Additionally, I don't necessarily want a key sitting out there that will let any random person who finds it a dynamic way to look up my current IP address. It's not the worst thing in the world, but it's definitely not something I'd publish publicly.
I stick with Resilio for this reason. For over a decade now it had been a 100% reliable fire and forget tool.
You don't have to do that with Syncthing. See https://docs.syncthing.net/users/introducer.html
> The introducer feature lets a device automatically add new devices. When two devices connect they exchange a list of mutually shared folders and the devices connected to those shares. In the following example:
> Local device L sets remote device R as an introducer. They share the folder “Pictures.” Device R is also sharing the folder with A and B, but L only shares with R.
> Once L and R connect, L will add A and B automatically, as if R “introduced” A and B to L.
> Remote device R also shares “Videos” with device C, but not with our local L. Device C will not be added to L as it is not connected to any folders that L and R share.
In short, it's a great tool, it works well in general, but the initial setup is pretty cumbersome if all I want to do is send a couple files to someone.
Additionally, I've had a couple time where even just syncing between my own devices broke. I think it was something where files were changed on both sides and the reconciliation algorithm got confused, but it was hard enough to debug for me, with direct access to both devices, and decades of experience running and programming computers, that I'd never want to try to debug that over the phone with a friend.
It's worth checking exactly what is encrypted as I don't think folder and file structure and names were encrypted.
Can you tell me what this feature is called?
It's a setting you can find in the advanced tab of devices.
Lately I've also started self hosting Pairdrop.[2]
1. https://timvisee.com/projects/send/ 2. https://pairdrop.net/
POWER TO THE PIRATES
Signed GOG installer? That'll be fine.
File checksum matches known scene release? That'll be fine.
I've heard of more people getting infected via Steam than by torrent downloads recently (see: Slay the Spire on Christmas day).
python -m http.server 8080
then from my phone I just use a browser.
https://github.com/nwtgck/go-piping-server
After starting the server, a few options.
Method 1: Visit https://127.0.0.1:8080 in a Javascript-enabled browser and fill out HTML form
Method 2: Visit https://127.0.0.1:8080/noscript in any browser and fill out HTML form
Method 3: Use any TCP or HTTP client. For example here is a quick and dirty shell script
#!/bin/sh
test $1||exec echo usage: $0 something file
test $2||exec echo usage: $0 something file
x=$(stat -c %s $2)
{
printf 'POST /'$1' HTTP/1.1\r\n'
printf 'Host: 127.0.0.1\r\n'
printf 'Content-Type: multipart/form-data; boundary=\"yxxxxzxxxzxxxzzxyxzx\"\r\n'
printf 'Content-Length: '$x'\r\n'
printf 'Connection: close\r\n'
printf '\r\n'
cat $2
echo ---yxxxxzxxxzxxxzzxyxzx
} \
|nc -vvn 127.1 8080
laptop> 1.sh whatever 1.pdf
phone> curl http://127.0.0.1:8080/whatever > 1.pdf
laptop> 1.sh 1.pdf 1.pdf
On phone, type into browser: https://127.0.0.1:8080/1.pdf
This file is saved as 1.pdf
YMMV
Replace 127.0.0.1 with an appropriate address for computers on the LAN, e.g., RFC 1918 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12.
The README mentions that it's an alternative to both Dropbox and WeTransfer. My current alternative to Dropbox is Nextcloud, and my current alternative to WeTransfer is (formerly Mozilla) Send. What's the added value of YouTransfer compared to this solution?
I'm also put off by the fact that the README has a big "looking for a new maintainer" disclaimer on top, and the demo page doesn't even work. Sure, I could put enough effort into maintaining a project if I see its added value, but in this case it seems to be a product trying to sneak into a market where there are already viable and well-maintained open alternatives.
I also use Nextcloud but use the Floccus browser extension to sync bookmarks to Nextcloud. Works well when it works.
Not saying it is most efficient, but for non tech friends, that may be an option.
It's abandoned, though.
For non sensitive data, ufile.io is the most decent drop app I could find. Been around for a while and am surprised they haven't yet spoiled it with dark patterns, removal of free tier, sold out.
For sensitive data, Google drive. Share.
For very sensitive data, encrypt, ufile.io, or Google drive. decrypt on the other end. Quite a pipeline but note that it paradoxally doesn't require a self hosted drop app.
Ipfs? Still not nearly as simple as via google drive, needs native app app running. Drains phone batteries, requires manual encryption for anything sensitive as file access can't be gated.
Blockchain? Except for tiny blobs, impossible.
a p2p app that use some open KPI for encryption would be great.