Feature discussion: multi-user support, aka server deployment (vs single user desktop app deployment)

[curiousercreative]

First, let's recognize this as a major feature discussion that may very likely not align with the goals of this project, but as Ansel links to this project as the future (a probable migration path from darktable) I'd like to start a discussion here (or wherever the community prefers). Over the years, many have used darktable and liked it a lot, but struggle with multi-user. For example, just my partner and I struggle to share a library and access from just two different desktops. So, here are some user stories (all from software user unless otherwise noted):

1. I need to access my library from any device and from anywhere
   1. I need to ingest images
   2. I need to cull images
   3. I need to manage images (rate, star, flag, tag, etc)
   4. I need to export images (chosen format, size, etc)
   5. I want to edit images
2. I need to view (read) my library at the same time as one or more other users
3. I want to edit (write) my library at the same time as one or more other users

There's a lot of details to unpack from these, but I hope it's a good starting point. I understand that darktable was never focused on DAM features, but I'll say that it's full-featured enough and I've yet to encounter a reasonable workflow that isn't a DAM and editor tightly coupled (typically as a single application).

Thanks for reading through, looking forward to discussion.

[curiousercreative]

In case it's helpful I partially (and limitedly) satisfy some of these needs and desires with:

• darktable as desktop DAM, processor, and editor
• two 10G LAN desktops with masters, thumbnail cache, library, db, etc centralized on NAS
• photoview as read-only gallery for viewing library (ratings, etc not synced with darktable) and exporting (limited options, but masters supported). NOTE: Immich is another option now for read-only from existing directory.

[hanatos]

okay, let's discuss. let me throw in a few comments:

interesting. you run darktable asynchronously on two computers operating on the same files over NAS? i suppose you're running sequentially, on one xor on the other computer? the sqlite backend is not multi-user. darktable likely has measures in place to avoid opening the same db twice, i don't remember.

database people laughed at me for using a database for a single-user application in the past.. so i suppose this is why vkdt does not have a database backend at all. everything is only stored in human readable text files next to the images.

as far as star ratings, edit history, and per-directory filter and sort preferences are concerned, vkdt supports a sequential multi user workflow. as long as you're sure nobody else is working on the same directory (i.e. writing changes), all the data is local/synchronised with the raw files in the directory and the text files next to them.

i feel like immich is a sufficiently different application that should well complement the feature set of an editor.

[curiousercreative]

@hanatos thanks very much for the prompt response. I thought I'd demo vkdt a bit prior to responding but I've thus far been unable to (I'm on Ubuntu 22.04 derived Pop!_Os not meeting minimum glibc version dependency for provided builds). I've leave a few comments here, but don't expect it to drive this discussion forward, rather just better context for anyone else to participate in the discussion.

interesting. you run darktable asynchronously on two computers operating on the same files over NAS? i suppose you're running sequentially, on one xor on the other computer? the sqlite backend is not multi-user. darktable likely has measures in place to avoid opening the same db twice, i don't remember.

Yes, not at the same time. darktable does create a lockfile to mitigate concurrent access to database.

database people laughed at me for using a database for a single-user application in the past.. so i suppose this is why vkdt does not have a database backend at all. everything is only stored in human readable text files next to the images.

text files = xmp sidecars? I understand large libraries become hard to query in such case, but perhaps vkdt is not concerned with this (DAM feature) or has cleverly solved without a db.

i feel like immich is a sufficiently different application that should well complement the feature set of an editor.

Yes, though I'll point out that neither Photoview nor Immich are full fledged DAM applications. There's little to no querying capability, no culling tools, no 5 star rating, etc, etc. Whether it's extending these existing apps or whether it's a new web app, I agree that separating DAM and editor offers many benefits if the integration is exceptional.