Seems to work well, at least between my Linux desktop and my wifi-connected Android phone; both showed up without any hassle, and sending files each way was boring in the best of ways.
It also supports something it calls "Private Room," which doesn't require the endpoints to be on the same LAN. This also works well, at least with my phone on 5G and the Linux box ultimately connected with DOCSIS.
No idea how many intermediaries, if any, are involved with any of this, and for my normal purposes I don't care at all.
It was easy for all of 6 or 7 months on android until someone at google realised their quick share feature prevented them from getting your data and subscription money and proceeded to immediately shoot themselves in the foot.
Yeah, I'm pretty sure these are all descendants of SnapDrop, but development or hosting or both seem to keep dying off the various forks every few years.
That one is, apparently, now owned by whoever also owns the zombie brand of LimeWire.
Nice design, but that's the kind of functionality that's best integrated within a chat or videoconferencing application, since within a conference you can be pretty sure that you send the file to the right person.
For a demo, go to <https://galene.org:8443/group/public/hn/>. Login twice in two different browser tabs (leave the password field empty). Click on the username of your partner, and choose Send file.
No, it's best to write the data on a USB stick and see the person in real life. Ask for ID and do a retina scan. Then you can be pretty sure that you give the file to the right person. Make sure to cryptographically sign the data so the recipient can be sure it's you.
In modern conferencing applications, users are not connected with each other, they are connected with a central server.
Transferring files shouldn't involve that central server, so you'd need to establish a direct connection between the users, and with network topologies those days, it will most likely require a relay between the two. It's not great.
> Transferring files shouldn't involve that central server, so you'd need to establish a direct connection between the users
That's exactly what Galene does when a user requests a file transfer.
> with network topologies those days, it will most likely require a relay between the two
We perform NAT traversal by using the server to punch holes in both NATs. Only if that fails (due to a symmetric NAT or to an overly restrictive firewall) do we fall back to relaying through the server.
Seems to work well, at least between my Linux desktop and my wifi-connected Android phone; both showed up without any hassle, and sending files each way was boring in the best of ways.
It also supports something it calls "Private Room," which doesn't require the endpoints to be on the same LAN. This also works well, at least with my phone on 5G and the Linux box ultimately connected with DOCSIS.
No idea how many intermediaries, if any, are involved with any of this, and for my normal purposes I don't care at all.
It's crazy that in 2026, transferring files between two random, willing, devices is still a hassle.
It was easy for all of 6 or 7 months on android until someone at google realised their quick share feature prevented them from getting your data and subscription money and proceeded to immediately shoot themselves in the foot.
thank konqi for kde connect.
Wait, what happened to quick share?
It's being limited
https://www.androidauthority.com/android-quick-share-removin...
(I wonder if this is a demand from the Chinese state, because when Apple modified airdrop it was because protestors were using it to spread ... well read https://www.theguardian.com/world/2022/nov/11/apple-limits-i... )
Try localsend https://localsend.org/
Localsend is great, I use it a lot for random stuff!
Operating system makers would rather sell you a subscription to OneDrive, iCloud, or Google Drive.
Solution I've been using for a while is KDE Connect. Works on windows, linux, android
I was using it for a while, then something somewhere broke (now it's unable to pair). I haven't really looked into it again since.
Not anymore with this?
Reminds me of https://sharedrop.io
It's apparently a fork (Github Readme)
Yeah, I'm pretty sure these are all descendants of SnapDrop, but development or hosting or both seem to keep dying off the various forks every few years.
That one is, apparently, now owned by whoever also owns the zombie brand of LimeWire.
This is a similar tool, but it's more like a Swiss Army knife: https://github.com/nuwainfo/ffl
Nice design, but that's the kind of functionality that's best integrated within a chat or videoconferencing application, since within a conference you can be pretty sure that you send the file to the right person.
For a demo, go to <https://galene.org:8443/group/public/hn/>. Login twice in two different browser tabs (leave the password field empty). Click on the username of your partner, and choose Send file.
No, it's best to write the data on a USB stick and see the person in real life. Ask for ID and do a retina scan. Then you can be pretty sure that you give the file to the right person. Make sure to cryptographically sign the data so the recipient can be sure it's you.
I used your demo. It does not do what you say that it does.
I opened a tab and signed in as "username".
Then I opened another tab and signed in as "username" there, too.
Thus a shared chat exists with two users named "username".
Whatever this is, it is not the path of disambiguation.
In modern conferencing applications, users are not connected with each other, they are connected with a central server.
Transferring files shouldn't involve that central server, so you'd need to establish a direct connection between the users, and with network topologies those days, it will most likely require a relay between the two. It's not great.
> Transferring files shouldn't involve that central server, so you'd need to establish a direct connection between the users
That's exactly what Galene does when a user requests a file transfer.
> with network topologies those days, it will most likely require a relay between the two
We perform NAT traversal by using the server to punch holes in both NATs. Only if that fails (due to a symmetric NAT or to an overly restrictive firewall) do we fall back to relaying through the server.
I don't agree with this.
File Transfer https://m.xkcd.com/949/
shameles self promotion: I posted similar thing a couple of days ago:
https://news.ycombinator.com/item?id=48773805
https://9.1-1-1.de