The best and recommended way to connect to copyparty (either from windows, linux, or macos) is with WebDAV – this will give you much higher performance. WebDAV is also a MUCH safer choice when connecting over the internet, since it is just https after all. Meanwhile, exposing SMB to the internet is generally a recipe for, well… nasty surprises :-)

There are also very copyparty-specific reasons to not use the SMB-server, and these are explained in the readme. That’s also why the SMB-server is not possible to enable in any of the official copyparty distributions without manually obtaining the necessary dependencies for that (impacket).

There were comments about security risks though, based on being a small project with a LOT of integrations.

time will show, but the only thing i actively regret adding was the support for discord embeds (the “og” option); opengraph is an awfully designed concept and, unrelatedly, it has been a source of a handful of bugs in how it was implemented in copyparty (that one’s on me). Keeping that disabled avoids a lot of edgecases, most of which are decreed by the opengraph spec.

That said, there’s no features keeping me up at night; i think for the most part things are fine – just don’t enable the smb server 😁

sooo this is one of the things that started with someone saying “wouldn’t it be funny if…”

if you open copyparty-sfx.py in a text editor, you’ll see how – but please make sure to use an editor which is able to handle about 600 KiB of comments which contain invalid utf8 / binary garbage 😁

I ended up rolling my own packer since I wanted optimal encoding efficiency, and everything I could find would do stuff like base85 or ucs2 tricks, but it turns out python is perfectly happy with binary garbage in comments if you declare that the file is latin-1 so it realizes all hope is lost :D

the only drawback of the sfx.py is that it needs to extract to $TEMP before running, so that’s the slight advantage of the zipapp (the .pyz alternative), but that suffers from some performance reduction in return, and is more hermetic (doesn’t let you swap out the bundled dependencies with fresh versions as easily if necessary)

Yep – https://github.com/9001/copyparty/tree/hovudstraum/scripts/docker

Hopefully that description makes sense (let me know if it doesn’t)

thanks for the vote, I hear ya :>

BTRFS and ZFS support real deduplication via copy on write, and would eliminate all current disadvantages of symlink and hardlink deduplication. It just works.

yeah that’s a good point, I’ll add an option to take advantage of this if you know you’re running on a filesystem where that works as intended.

Why have it be one huge python source file?

oh don’t worry, it’s all separate files during development – there’s a build-stage which bundles everything up into a single file for distribution. But thanks for the concern :D

Thanks a lot for the kind words! ready to answer questions if you hit any bumps :>

If all you need is basic remote file storage such as a samba server, and especially if you need samba in particular, then your current solution is probably a better fit for you.

Copyparty’s main selling points is the large number of features in one package, and being pretty good at receiving file uploads (usually faster than other alternatives), but it does not have good samba support. Instead of samba, copyparty has WebDAV support, so you can still connect to it from your file manager – but the performance will be different; depending on your access pattern and the type of files, it could be faster or slower than samba.

So I realize the following does not directly apply in this specific case, since we are talking about a full android app. But in general, there are strictly technical limitations which absolutely requires you to use https. This for example applies to PWA’s, and it also applies to apps which are WebView-based.

Basically the w3c is disagreeing with you; there are several important javascript features which are forcefully disabled if you are not connecting over https. This is a decision made by the webbrowser itself, and not something you or the dev can disable or otherwise avoid.

For example, it is impossible to use the browser’s built-in api for getting the sha512 hash of a file, which is why i had to go through great pains to do that in other suboptimal ways in one selfhosted service i made. Most devs rightfully wouldn’t bother, since those restrictions are arbitrary and effectively pointless, as there are (usually painful) workarounds.

List of features which require https: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts

off topic, but out of curiosity - why ogg (presumably vorbis) in favor of opus? maybe old devices or players, or just haven’t made the change yet?

opus is also a xiph project, and is almost entirely transparent at “128kbps” (it’s a misnomer for the q4 of vorbis), so it uses way less space for the same quality. I warmly recommend giving it a try if you haven’t already.

I’ve started blocking entire AS from my servers; since I only expect/want traffic from home ISPs it’s kinda alright, but still… man

HFSv2 (the windows exe) has publically known unfixed vulnerabilities! Please upgrade to HFSv3 (nodejs, crossplatform). I’m also maintaining a list of other alternatives; https://github.com/9001/copyparty/blob/hovudstraum/docs/versus.md

I’ve been making copyparty, and one of the initial inspirations/usecases was exactly this one – bunch of internet-friends meeting in meatspace for some event, and needing to stream across pics/vids before we split up and maybe never meet again :-)

You can run the server on android using termux; see the instructions in the readme for the installation part, and then run the server like so: copyparty -e2ds --qr -v /storage/emulated/0/Pictures/from-family/::w

it will show a QR-code which you can scan from the other device to start uploading, and the folder is shared write-only (:w instead of :rw), so nobody can download anything. And it keeps track of which files have already been transferred, so the client will skip across dupes without reuploading them, and also resume interrupted uploads automatically.

Tried sending 340 photos (1.21 GiB) from an old iPhone to an android hotspot just now; I turned off the iPhone screen as soon as it started sending, and it finished in 41 seconds, so around 30 MiB/s? Maybe there are faster alternatives… But my javascript should be fairly resilient and recover from network glitches and such, so uploading from safari like this should be fine.