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 😁

hfs v2 (the old banger of an exe) is no longer being maintained and has some known unfixed vulnerabilities, however there is now a rewrite (hfs v3) which is shaping up really nicely.

should also mention that copyparty is also available as a windows exe which will run without python or any other dependencies

No worries, good question :>

The problem with bidirectional filesync is that it’s an absolutely massive can of worms, very easy to mess up, and the consequences of messing up are usually the worst kind (loss of data). There’s an insane amount of edgecases to keep in mind, and you need to get every edgecase right every single time, otherwise you might wipe someone’s vacation photos, or suddenly downgrade someone’s keepass database to an older version… And stuff like syncing multiple devices to the same server makes it balloon further.

I’ve started becoming more confident in copyparty’s filesystem-index database, but it’s still just a hint/guideline, with the filesystem being the only source of truth – it’s still not something I’d trust with tracking sync-state against one or more clients.

The bigger guys who offer bidirectional sync (nextcloud, syncthing, etc.) have spent years perfecting their logic, so I’d like to leave this in their capable hands.

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! Depending on what your home connection looks like, you have a few options:

if you are lucky enough to have your own private IP-address and are able to open ports, then you’re almost done already – you can put copyparty on some port (or keep the default 3923), and then anyone could connect to it by going to https://your.ip.address:3923/

(with this approach, you will want to create your own HTTPS certificate so the traffic is properly encrypted – the best option here is to get a domain and get a certificate for the domain)

however, if you are behind CGNAT, meaning your internet provider has given you a shared IP-address, then people cannot connect directly to your home-PC. One way around that issue is by setting up a machine somewhere on the internet which bridges the gap back home to your PC. Cloudflare offers this as service, and this is explained in the copyparty readme – see the “at home” section for one way to do that.

if you are against using Cloudflare for idealistic reasons (they are becoming quite powerful since they run a whole lot of the internet), then you can set up a cheap VPS which serves the same purpose. That’s my setup, and how you are accessing the copyparty demo server right now – I have the cheapest VPS you can get from Hetzner. The VPS is running nginx, and it forwards the traffic to my homeserver through an SSH tunnel. I haven’t documented this approach in the copyparty readme, but I have a feeling a lot of other people have :>

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

I was thinking of that!! But then I realized that even Firefox removed gopher support by now, so the joke was dead on arrival :P

As long as it’s not causing any issues or drawbacks for modern python versions (and it isn’t), I don’t see any reason to do that – on the contrary, I know people are running copyparty on retro equipment, so I’d very much prefer to keep it for as long as possible :>

SFTP is not currently on the roadmap, but it’s not entirely implausible.

FTPS is supported, but it requires an optional dependency to be installed (pyopenssl), so it’s not available in the Windows EXE. And I just realized that the dependency is currently not present inside the docker images either, so I’ll get that fixed right away.

That’s a neat idea – I’ve heard that a lot of stuff uses the subsonic API under the hood, so I’ll see what it would take to become compatible with that. At first glance it looks like I’d have to mine and index way more information about audio files, but could still be doable :>