Using Copyparty for Tag-Based File Management

[Mirodin]

I’ve been using copyparty for some months now and appreciate its flexibility. One idea I’ve been exploring is using it for a tag-based file management system, where files are organized primarily by tags and metadata rather than folders.

Currently, I manually tag files (e.g., 20260310 Lasers & Feelings _rpg _system.pdf), inspired by Karl Voit’s approach. This works well for searching, but I’d like to attach additional metadata, such as source URLs or custom notes.

Given copyparty’s -mtp flag, I’m curious if it could be leveraged to support sidecar XMP/JSON/... files or alternatively a file in the .hist folder for storing metadata. Has anyone tried something similar, or are there existing features or plugins that could help achieve this?

I’d appreciate any thoughts or suggestions on how to implement this effectively.

[vladlen-codes]

As far as I know, I can suggest you a few things on the approach, On -mtp for sidecar metadata:
The -mtp flag is primarily designed for metadata parsers that extract tags from files during indexing.
You could potentially write a custom -mtp parser that:

• Detects sidecar .xmp or .json files alongside your tagged files.
• Extracts their metadata into copyparty's tag database at index time.
  This would make the sidecar metadata searchable within copyparty's existing tag system.

On .hist folder storage the copyparty already uses .hist for some internal metadata, storing custom sidecar data there is an interesting idea but may conflict with copyparty's own usage. Worth checking the docs carefully before going this route.

An alternative approach could be using filename-based tagging, a lightweight JSON sidecar with the same base filename (e.g., 20260310 Lasers & Feelings _rpg _system.json) would be portable, human-readable, and easy to parse with a custom -mtp plugin.

[Mirodin]

Thank you for confirming my assumption that using the -mtp flag might be a good starting point.

A few years back I wrote a little blob storage system that saved files using their SHA1 hash (like sha1-1234...) and kept a JSON sidecar file (e.g., sha1-1234.json) next to each one for metadata—things like source URLs, tags, or notes. On startup, it would load all the metadata into memory and let me search through it using a simple HTTP API. The API itself was pretty janky—just GET requests with a bunch of URL parameters—but it worked well enough for my needs.

The code is honestly a mess (I was teaching myself programming back then), but it’s been surprisingly useful over the years. Since I only have around 20,000 files, memory hasn’t been an issue, and I never felt the need to switch to a "real" database.

So that is why I would love for copyparty to take over since there are so many additional features my implementation does not have i.e. no login, rights management or even basic security (though deletion is not possible so there is that).

[vladlen-codes]

I see, your use case maps well to copyparty's existing features like:

• SHA1-based deduplication: copyparty already tracks file hashes internally, so your content-addressed storage approach aligns naturally with how it works under the hood.
• Tag search: copyparty's tag system with -mtp parsers could replace your HTTP API search, with a much nicer UI.
• Login and rights management: copyparty handles this out of the box, which directly addresses your security concerns.
• 20,000 files: well within copyparty's comfortable range, so performance shouldn't be a concern.

Migration path I would recommend worth considering:

1. Write a simple -mtp parser that reads your existing .json sidecar files and maps their fields to copyparty tags.
2. Let copyparty index your existing files, it will pick up the SHA1 hashes naturally.
3. Your existing metadata becomes searchable through copyparty's tag system immediately.