I think this is what Daniel was really asking: that he wanted one library, but with retained file ownership and access authorizations.
In prior sharing discussions, I’d tried to simplify the design by completely avoiding “users”. Access to a tag or asset would only be via a share token:
What you guys are saying is that PhotoStructure really need users, where each user has a role, and permissions to an asset or tag should be granted to users, rather than simply using access tokens. Something like this:
Where “role” is something like “owners”, “contributors”, and “viewers”:
viewers can only view or comment on a tag or asset
contributors are viewers that can also add new assets and hide existing assets
owners are contributors that can also allowed to delete assets
If an asset has no associated user, it defaults to the library owner(s).
There are a couple things to think about here:
Using filesystem user/group/ACLs
PhotoStructure would need
CAP_CHOWN to copy files into the library across volumes and retain prior user/group file ownership. I’m not aware of an equivalent on macOS or Windows.
This would require PhotoStructure to run as an admin, which is not acceptable, which is why this option isn’t acceptable.
Using external metadata
If asset ownership could be inferred and stored as metadata:
the “automatically organized” library assets would all be owned by the user that PhotoStructure runs as
the scanned directories would need to be readable by the user that PhotoStructure runs as, and writable if metadata persistence was needed, or move-on-import was enabled.
scanned directories could be annotated with a PhotoStructure owner (either via a system setting or with a
.photostructure.toml file that sits in the directory and is applied recursively). This would support something like resilio sync on your NAS syncing a family’s different file and folders, and each root sync folder could be annotated with ownership.
- some unique name (possibly their email, or a shorter handle)
- if the user is a library “owner”
(I don’t think the idea of “visitor” or “contributor” makes sense for a whole library: what do you think?)
To get your desired feature of having a single PhotoStructure library support several different users, each with their own private library: you’d have one “admin” user, but normally log in with your “normal” user that only has access to your files.
A reasonable future feature would be allowing users to share ownership of an asset or group of assets with someone else via the UI.
User authentication within PhotoStructure libraries
I’m planning on supporting both external authentication (say, via cloudflare teams or other reverse proxies) and authentication within PhotoStructure (via what amounts to api access tokens: just username and access token).
We need a mapping between externally authenticated users and internal PhotoStructure users to grant those users their roles.