Hacker News Reader

Comment by spieglt | Hacker News Reader

Mine does! https://github.com/spieglt/flyingcarpet

Thanks for the link. Looking through the Github, this appears to be close to what I'm looking for on my own project. Namely, being able to share files automatically with nearby devices when they move within range.

I thought Bluetooth might be viable, as beacons and GattServers seem to be designed for this purpose. Android's implementation was painful, yet doable. However, after wading into Microsoft's codebase, I suspect it will be slog.

Question: With an agreed upon network name or configuration, and agreed upon access parameters, how much change do you think it would take for FlyingCarpet to instead by used as a semi-anonymous, dynamic membership mesh network?

Ex: A laptop and a phone get near each other, they recognize their proximity, and that they are both offering the known network, they then check for the presence of known filetypes in a known folder location, and exchange small updates with each other. The same with any number of desktops, laptops, or phones that get near each other. If I was in a mall with 11 other similarly configured phones nearby, and 5 people working on laptops, then my phone would call the 16 other devices, and they would each get a file from my phone, and I would get a file from their phones.

It's a very cool idea, but the first barrier that comes to mind would be that when the clients join the hotspots, they don't have internet access, so joining the network would mean losing internet, for laptops and phones without cellular data. I know the LocalOnlyHotspot API I use on Android doesn't offer internet tethering. I'm not sure how possible it is to ensure that on Windows and Linux devices that host hotspots. Also, the device that offers the hotspot in Flying Carpet is pretty much acting like a normal WiFi access point in infrastructure mode, so a real mesh network would probably look a lot different.

Thanks. Those are the kind of issues I was worried about with a superficial glance. The general idea looks tempting ("send files to nearby devices"). However, dropping connectivity every time would probably be a deal breaker. I was hoping you might be able to connect for like 10-20 seconds, grab a few kB of files, and then continue on your way, having a spotty, partial connectivity to other devices while wandering the above mall scenario.

Great project! Thank you for building it.

If the UI was simpler and more "Apple-like" (hate to say this) I could convince my non-tech coworkers/family/friends to use it.

Also, could you auto detect the other peer's OS? You could skip an extra step and UI element. Do you need it to know which WiFi bandwidth to use?

Thank you! Yeah, obviously the UI is a weak part. I'd like to improve it eventually but as a one-person project I don't want it to have as minimal of an interface as AirDrop. With all the ways transfers can go wrong, I want that information to be in the user's face so they can submit issues and I can help debug easily.

And no, it can't detect anything about the other device until they're on a WiFi network together, and that can't happen until it knows the peer's OS because it has to know whether it or the peer should be hosting the hotspot. Windows has precedence, then Linux, then Android. (The iOS version doesn't need to know the peer's OS because iOS and macOS can't stand up a hotspot programmatically anymore, so it always has to join.)

So how would a transfer between two iOS devices work? Neither would be able to create the hotspot, right?

Correct, Flying Carpet doesn't work for Apple-to-Apple transfers, but AirDrop already fills this need.

Thank you for the detailed explanation, it's not my specialty yet really fun to scratch a bit of the surface in other aspects :)

I used this a while ago, thanks!

Great to hear, thanks for letting me know it worked!

This serves the purpose of cross-platform file sharing. Great job.

Haven't tried yet but this is really cool. Nice job.

Excellent work.

Reply on news.ycombinator.com