171–180 of 363 posts
I self-host a Nextcloud instance. If it's too big for a browser download, Bittorrent is the way to go.
Earlier quoted context omitted.
That’s a really cool idea actually
Same thing happens in Greece with buses. It's a very popular way for moms to send home-made food to their single/university student sons.
Earlier quoted context omitted.
Sometimes I wonder if the bad connotation due to piracy made this protocol not standard (in a sense, that's not widely adopted, and people need dedicated clients, instead of it working for example in browsers). I don't know enough, maybe it has security issues, or some limits... but the fact is that it's still widely used, by tech literate people, so it still stands the test of time and it must be doing something rig…
WebTorrent [1] can be used to run BitTorrent on the web. It's actually integrated into the Brave browser which is a nice feature. Other browsers might catch on soon. [1] https://webtorrent.io/
You can create a simple python http server to expose files in a directory to the local web: $ python -m http.server 8000 and then you can start ngrok to expose the file $ ngrok http 8000 that will give you an URL to share with whoever wants it.
ngrok is an amazing utility though!
Earlier quoted context omitted.
WebTorrent [1] can be used to run BitTorrent on the web. It's actually integrated into the Brave browser which is a nice feature. Other browsers might catch on soon. [1] https://webtorrent.io/
WebTorrent is pretty limited though: > ... a browser-based WebTorrent client or "web peer" can only connect to other clients that support WebTorrent/WebRTC. (from https://webtorrent.io/faq ) This essentially splinters the world into the bittorrent and webtorrent halves, which makes it far less useful.
Bittorrent. No, really. Lots of nice behaviors when transferring large amounts of data between arbitrary endpoints. Transferring the torrent metadata is pretty trivial and can be done via a wide range of methods, and having that flexibility can be nice. Unlike HTTP, you get reasonable retry behavior on network hiccups. Also, more robust data integrity guarantees, though a manual hash test is probably a good idea eith…
> Unlike HTTP, you get reasonable retry behavior on network hiccups Seriously. Zmodem/resume was doing better in 1986.
Bittorrent. No, really. Lots of nice behaviors when transferring large amounts of data between arbitrary endpoints. Transferring the torrent metadata is pretty trivial and can be done via a wide range of methods, and having that flexibility can be nice. Unlike HTTP, you get reasonable retry behavior on network hiccups. Also, more robust data integrity guarantees, though a manual hash test is probably a good idea eith…
For this reason I prefer using something like Syncthing which is designed more with this purpose in mind.
Earlier quoted context omitted.
Magic Wormhole is good. These days I use croc,[0] which I find even better. [0]: https://github.com/schollz/croc
I never understood why croc chose to copy the features of Magic Wormhole but implement them in an incompatible way. Partially out of my annoyance with this I implemented a port of Magic Wormhole in Go that fully interoperates with the official python version: https://github.com/psanford/wormhole-william
I chose not to copy the features of magic wormhole because it seemed to me (at the time) to be very complicated and lacking in features crucial to myself (namely restarting transfers [1], sending folders without zipping them).
This has been to my benefit, I think, because I can iterate on croc quickly without having to conform to the wormhole spec and I've since added features still not available in wormhole (like restarting transfers [1], and ipv6 support [2]).
That being said, I really like magic wormhole and consider it my inspiration. And I'm glad that you ported it to Go!