Consider IPFS?

[MidnightLightning]

The structure of how copyparty manages files by dividing them into chunks, then knows the hashes of each chunk, and can deduplicate chunks sounds very similar to how IPFS manages its data as well. IPFS identifies files by a "content identifier" (CID) which is the hash of the file, and so translating the inner storage of copyparty files into IPFS CIDs would likely not be too big of an adaption.

How could this be helpful? If copyparty becomes a UI for the IPFS protocol, every copyparty instance could communicate with every other copyparty node (and any other IPFS nodes). Using the IPFS bitswap communication layer, a copyparty node could ingest data by CID ("uploading" from a peer node), and could recover a corrupted chunk by asking peers if they have it, and share files with another sector of users. For users wanting to use copyparty to host files to be available to the public, sharing them via IPFS would easily "load balance" them by making the files accessible by any IPFS node.

[9001]

it's a shame to pass up this overlap of design and concepts, but I'm afraid copyparty is too tightly coupled to communicating directly with a conventional filesystem, so I don't expect this to happen. Sorry!

[MidnightLightning]

I think IPFS would not be a replacement for the underlying filesystem, but my thought was it could be an addition like "FTP"; another protocol it could communicate as. IPFS is a communication protocol, rather than having a say in how the server node keeps the data. Does that change the perspective any?