Better sharing in Immich (feature freeze) #3831

Author

Owner

@aviv926 commented on GitHub (Oct 21, 2024):

It would be great to see the smart search integrated into shared albums, and especially if they are shared via a link, this way even those who don't have an Immich account (a friend from work with whom the album is shared) will be able to use the smart search to find a specific image.

@aviv926 commented on GitHub (Oct 21, 2024): It would be great to see the smart search integrated into shared albums, and especially if they are shared via a link, this way even those who don't have an Immich account (a friend from work with whom the album is shared) will be able to use the smart search to find a specific image.

deekerman commented

Author

Owner

@GD-Dal commented on GitHub (Oct 28, 2024):

I think there should be a difference between sharing and several people collaborating on the library.
It is a great desire from me to have many people maintaining the library, including access to all tags folders, etc

Sharing could be if you wanted to show some pictures (read-only) to someone without creating accounts for them, etc

Wishes:

The ability to have many people maintain the library
Nested albums
Groups of people, and the ability to give access to library / albums with groups. Today, when trying to share 30 albums with someone, it can be very tiresome
Create albums based on tags
Search based on tags
Everyone gets access to tags and folders

I hope these features are being worked on. Basically the only things missing as of now

@GD-Dal commented on GitHub (Oct 28, 2024): I think there should be a difference between sharing and several people collaborating on the library. It is a great desire from me to have many people maintaining the library, including access to all tags folders, etc Sharing could be if you wanted to show some pictures (read-only) to someone without creating accounts for them, etc Wishes: - The ability to have many people maintain the library - Nested albums - Groups of people, and the ability to give access to library / albums with groups. Today, when trying to share 30 albums with someone, it can be very tiresome - Create albums based on tags - Search based on tags - Everyone gets access to tags and folders I hope these features are being worked on. Basically the only things missing as of now

deekerman commented

Author

Owner

@Zvirovyi commented on GitHub (Nov 19, 2024):

I agree with the @jeffrpowell. I've recently discovered that facial recognition doesn't work with partner-shared photos and it's very confusing as I can't find mentions of this limitation in the documentation - nor in the "Facial Recognition" or "Partner Sharing" sections.

@Zvirovyi commented on GitHub (Nov 19, 2024): I agree with the @jeffrpowell. I've recently discovered that facial recognition doesn't work with partner-shared photos and it's very confusing as I can't find mentions of this limitation in the documentation - nor in the "Facial Recognition" or "Partner Sharing" sections.

deekerman commented

Author

Owner

@ghost commented on GitHub (Nov 20, 2024):

Think of the situation user A and user B are sharing photos using a shared album. At the moment user A can only tag his own photos in the shared album. It would be a nice feature that user A can tag his own photos and the photos shared by user B.

@ghost commented on GitHub (Nov 20, 2024): Think of the situation user A and user B are sharing photos using a shared album. At the moment user A can only tag his own photos in the shared album. It would be a nice feature that user A can tag his own photos and the photos shared by user B.

deekerman commented

Author

Owner

@Hutch79 commented on GitHub (Nov 27, 2024):

I come from the world of Synology Photos, where every family member has an account and can also access the shared space which contains photos of family events.

Maybe the spaces approach could be implemented with the partner sharing feature of Immich.
Imagine it like an "account" selector, where you can select who's photos you want to see. There you can select your own or any shared account and view it as if it were your own.
Depending on the perms given to you by its owner, you could also edit tags or peoples.

Don't really know how to call this, but it has nothing to do with this discussion.

I just started my journey with Immich a day ago, and I'm already very impressed.
The accuracy of facial recognition compared to Synology is astounding!
There are very few things I miss or have not found yet, on the other hand, there are features I will definitely miss on Synology.

What I want to say is basically how much I appreciate the work which is done here 💜
Thank you!

@Hutch79 commented on GitHub (Nov 27, 2024): I come from the world of Synology Photos, where every family member has an account and can also access the shared space which contains photos of family events. Maybe the spaces approach could be implemented with the partner sharing feature of Immich. Imagine it like an "account" selector, where you can select who's photos you want to see. There you can select your own or any shared account and view it as if it were your own. Depending on the perms given to you by its owner, you could also edit tags or peoples. <details><summary> Don't really know how to call this, but it has nothing to do with this discussion.</summary> <p> I just started my journey with Immich a day ago, and I'm already very impressed. The accuracy of facial recognition compared to Synology is astounding! There are very few things I miss or have not found yet, on the other hand, there are features I will definitely miss on Synology. What I want to say is basically how much I appreciate the work which is done here 💜 Thank you! </p> </details>

deekerman commented

Author

Owner

@jdmansour commented on GitHub (Nov 27, 2024):

I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-)

As Hutch79 mentioned, Synology Photos has a concept of a shared space where you can copy photos to. Something like a shared space or a family library would be great in Immich, I think. What I usually do is to move all the common photos to the shared space, and then we organize them together (remove bad ones, select favorites for print etc.). The one downside of the shared space in Synology is that you have to copy files to it, and it actually leaves two copies on the disk. It would be better if you could link Photos into the family library, set them to "shared with the family", "just for the family" or "just for me".

@jdmansour commented on GitHub (Nov 27, 2024): I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-) As Hutch79 mentioned, Synology Photos has a concept of a shared space where you can copy photos to. Something like a shared space or a family library would be great in Immich, I think. What I usually do is to move all the common photos to the shared space, and then we organize them together (remove bad ones, select favorites for print etc.). The one downside of the shared space in Synology is that you have to *copy* files to it, and it actually leaves two copies on the disk. It would be better if you could link Photos into the family library, set them to "shared with the family", "just for the family" or "just for me".

deekerman commented

Author

Owner

@greirson commented on GitHub (Nov 29, 2024):

This would be a huge improvement and help a great deal in my situations related to photo storage and management. Just to add to the conversation I have a few scenarios:

Sharing most of the day to day photos with my household/partner/kids, being able to collaborate on tags, people, places, etc.
We have a large family we'd like to collaborate with on albums related to family functions. Weddings, holidays, vacations etc. Different groups have different events, so separate access and collaboration controls would fill the need

Groups off the top of my head; Me+Partner, In Laws, My Parents, My multiple siblings families, my partners siblings families, my in laws 8+ siblings families, their adult kids families, extended aunties and uncles and cousins all over the place... Family Reunions are a shindig. Having nest-able groups to make a pyramid of permissions would be fantastic. Having my mother in law be able to sign on and add names to faces would be huge.

Ive had some family members pass away recently with boxes and boxes of photos we need to scan and digitize. Some are with me, some are with my father, some are with my aunt, etc. Being able to setup a group that everyone can upload photos to, that share metadata including faces, places, tags, etc.

I'd be willing to sponsor or add a bounty for these features if its an option

@greirson commented on GitHub (Nov 29, 2024): This would be a huge improvement and help a great deal in my situations related to photo storage and management. Just to add to the conversation I have a few scenarios: 1. Sharing most of the day to day photos with my household/partner/kids, being able to collaborate on tags, people, places, etc. 2. We have a large family we'd like to collaborate with on albums related to family functions. Weddings, holidays, vacations etc. Different groups have different events, so separate access and collaboration controls would fill the need > Groups off the top of my head; Me+Partner, In Laws, My Parents, My multiple siblings families, my partners siblings families, my in laws 8+ siblings families, their adult kids families, extended aunties and uncles and cousins all over the place... Family Reunions are a shindig. Having nest-able groups to make a pyramid of permissions would be fantastic. Having my mother in law be able to sign on and add names to faces would be huge. 3. Ive had some family members pass away recently with boxes and boxes of photos we need to scan and digitize. Some are with me, some are with my father, some are with my aunt, etc. Being able to setup a group that everyone can upload photos to, that share metadata including faces, places, tags, etc. I'd be willing to sponsor or add a bounty for these features if its an option

deekerman commented

Author

Owner

@kesteve commented on GitHub (Dec 5, 2024):

Hi I just reliazed Partner Sharing can't share recognized People, after some researches and I ended up here and I'd like to drop some comments.

I have a large External Library which takes me more than a week to generate thumbnail for it, and afaik an external library can't be owned by multiple users. So I assigned this library to an account and setup Partner sharing so multiple users can see the photos and videos in this library. However the People section is empty for other users now, I thought this is a bug, but end up this is a Partner Sharing limitation.

Is it possible that:

Allow external libraries to be owned by multiple users, and make sure Thumbnails / Metadata / Smart Search only needed to be generated once for the library. I know I can create multiple External Libraries and assign them for each user and pointing to the same mount point, but generating thumbnails really hurt and this will take me MONTHS to finish. Not to mention if there is any file path changes I'll need to generate again.
Allow recognized People to be shared by Partner Sharing as well.

For your information, I'm still using Synology Photos as my backup app, and Immich imported them as External LIbrary in read-only mode. I hope one day I can ditch the Synology Photos app and make everything works on Immich. Thank you so much for your hard effort on this app!

@kesteve commented on GitHub (Dec 5, 2024): Hi I just reliazed Partner Sharing can't share recognized People, after some researches and I ended up here and I'd like to drop some comments. I have a large External Library which takes me more than a week to generate thumbnail for it, and afaik an external library can't be owned by multiple users. So I assigned this library to an account and setup Partner sharing so multiple users can see the photos and videos in this library. However the People section is empty for other users now, I thought this is a bug, but end up this is a Partner Sharing limitation. Is it possible that: 1) Allow external libraries to be owned by multiple users, and make sure Thumbnails / Metadata / Smart Search only needed to be generated once for the library. I know I can create multiple External Libraries and assign them for each user and pointing to the same mount point, but generating thumbnails really hurt and this will take me MONTHS to finish. Not to mention if there is any file path changes I'll need to generate again. 2) Allow recognized People to be shared by Partner Sharing as well. For your information, I'm still using Synology Photos as my backup app, and Immich imported them as External LIbrary in read-only mode. I hope one day I can ditch the Synology Photos app and make everything works on Immich. Thank you so much for your hard effort on this app!

deekerman commented

Author

Owner

@dshanske commented on GitHub (Dec 29, 2024):

I've been looking to move to Immoch based on the recommendations of others. The software would be fine for me solo. But, I also maintain libraries of photos from relatives. I'd like to be able to maintain those albums collaboratively.

@dshanske commented on GitHub (Dec 29, 2024): I've been looking to move to Immoch based on the recommendations of others. The software would be fine for me solo. But, I also maintain libraries of photos from relatives. I'd like to be able to maintain those albums collaboratively.

deekerman commented

Author

Owner

@c00 commented on GitHub (Dec 29, 2024):

I would love to see (or help out) with a sharing feature that allows you to share a file to some s3 bucket, so that you can share outside of your local network. Of course during setup there should be a clear notification that this does share your files to some third party service. But it would be of great value to have the option to do that. Or some other mechanism to create links that are reachable for anyone, rather than just people in your network.

Alternatively, if immich was safe enough to host on a public server, that would work too. But as the docs seem to discourage that, another solution would be preferred.

Using s3 would make it very simple and versatile. We could even add timed links. We'd probably want some job to cleanup files that should no longer be shared. You could abstract the thing to support other external targets (sftp, dropbox, image hosting services, etc), but that might be a bit over-engineering it.

@c00 commented on GitHub (Dec 29, 2024): I would love to see (or help out) with a sharing feature that allows you to share a file to some s3 bucket, so that you can share outside of your local network. Of course during setup there should be a clear notification that this does share your files to some third party service. But it would be of great value to have the option to do that. Or some other mechanism to create links that are reachable for anyone, rather than just people in your network. Alternatively, if immich was safe enough to host on a public server, that would work too. But as the docs seem to discourage that, another solution would be preferred. Using s3 would make it very simple and versatile. We could even add timed links. We'd probably want some job to cleanup files that should no longer be shared. You could abstract the thing to support other external targets (sftp, dropbox, image hosting services, etc), but that might be a bit over-engineering it.

deekerman commented

Author

Owner

@github-cli commented on GitHub (Jan 11, 2025):

Where do the docs discourage that?
I know there is still a warning regarding it not being a stable release yet but that is to warn you to make sure you have backups. (Not saying there is no such warning that you mention, I just haven’t seen it)
I haven’t seen any security incident thus far either…

I have my immich exposed to the world for quite a while now (since the beginning).
Of course the surrounding setup needs to be setup properly and the password shouldn’t be something easy but I wouldn’t say you cannot make your immich public!
I share with immich to the other side of the world :D

@github-cli commented on GitHub (Jan 11, 2025): Where do the docs discourage that? I know there is still a warning regarding it not being a stable release yet but that is to warn you to make sure you have backups. (Not saying there is no such warning that you mention, I just haven’t seen it) I haven’t seen any security incident thus far either… I have my immich exposed to the world for quite a while now (since the beginning). Of course the surrounding setup needs to be setup properly and the password shouldn’t be something easy but I wouldn’t say you cannot make your immich public! I share with immich to the other side of the world :D

deekerman commented

Author

Owner

@c00 commented on GitHub (Jan 13, 2025):

Where do the docs discourage that?

In the remote access section at the bottom (emphasis mine):

Depending on your configuration, both the Immich web interface and API may be exposed to the internet. Immich is under very active development and the existence of severe security vulnerabilities cannot be ruled out.

I am probably more paranoid than most, but for me this is enough discouragement that I wouldn't expose Immich directly to the outside without a vpn.

@c00 commented on GitHub (Jan 13, 2025): > Where do the docs discourage that? In the [remote access](https://immich.app/docs/guides/remote-access#cons-2) section at the bottom (emphasis mine): > Depending on your configuration, both the Immich web interface and API may be exposed to the internet. **Immich is under very active development and the existence of severe security vulnerabilities cannot be ruled out.** I am probably more paranoid than most, but for me this is enough discouragement that I wouldn't expose Immich directly to the outside without a vpn.

deekerman commented

Author

Owner

@proud-nerd commented on GitHub (Jan 17, 2025):

+1 for sharing persons and face detection info via partner sharing. I mean a person is always the same, no matter who uploaded the photo. It just feels weird that my wife can see my photos in her timeline but can't see any face information on them nor find them via people search. I guess as long as this feature is missing, credential sharing it is for us.

Wouldn't it be easier to treat face detection and identification globally and not per user? That way all users can profit from one user putting in the time merging persons and everyone should get a higher accuracy.

Besides sharing them, the whole face detection feature feels really nice and just works great. UI/UX is fantastic, it's so easy to merge persons or correct assignments by hand.

@proud-nerd commented on GitHub (Jan 17, 2025): +1 for sharing persons and face detection info via partner sharing. I mean a person is always the same, no matter who uploaded the photo. It just feels weird that my wife can see my photos in her timeline but can't see any face information on them nor find them via people search. I guess as long as this feature is missing, credential sharing it is for us. Wouldn't it be easier to treat face detection and identification globally and not per user? That way all users can profit from one user putting in the time merging persons and everyone should get a higher accuracy. Besides sharing them, the whole face detection feature feels really nice and just works great. UI/UX is fantastic, it's so easy to merge persons or correct assignments by hand.

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Jan 17, 2025):

Wouldn't it be easier to treat face detection and identification globally and not per user?

No, this would have bad privacy implications on instances with users that don't know eachother.

@bo0tzz commented on GitHub (Jan 17, 2025): > Wouldn't it be easier to treat face detection and identification globally and not per user? No, this would have bad privacy implications on instances with users that don't know eachother.

deekerman commented

Author

Owner

@primetime00 commented on GitHub (Jan 17, 2025):

Wouldn't it be easier to treat face detection and identification globally and not per user?

No, this would have bad privacy implications on instances with users that don't know eachother.

Why would you be sharing with a user you didn't know in the first place?

@primetime00 commented on GitHub (Jan 17, 2025): > > Wouldn't it be easier to treat face detection and identification globally and not per user? > > No, this would have bad privacy implications on instances with users that don't know eachother. Why would you be sharing with a user you didn't know in the first place?

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Jan 17, 2025):

You wouldn't; the suggestion was to apply the face recognition globally, ie to every user.

@bo0tzz commented on GitHub (Jan 17, 2025): You wouldn't; the suggestion was to apply the face recognition _globally_, ie to every user.

deekerman commented

Author

Owner

@proud-nerd commented on GitHub (Jan 17, 2025):

Wouldn't it be easier to treat face detection and identification globally and not per user?

No, this would have bad privacy implications on instances with users that don't know eachother.

I meant that more in a technical way under the hood. The behavior right now makes me think persons are tied to one user at a time and my suggestion would be to have a global set of persons and then make them visible to all users based on what photos they are allowed to access. No one should see persons of photos they are not allowed to access ofc.

@proud-nerd commented on GitHub (Jan 17, 2025): > > Wouldn't it be easier to treat face detection and identification globally and not per user? > > No, this would have bad privacy implications on instances with users that don't know eachother. I meant that more in a technical way under the hood. The behavior right now makes me think persons are tied to one user at a time and my suggestion would be to have a global set of persons and then make them visible to all users based on what photos they are allowed to access. No one should see persons of photos they are not allowed to access ofc.

deekerman commented

Author

Owner

@Zvirovyi commented on GitHub (Jan 20, 2025):

I meant that more in a technical way under the hood. The behavior right now makes me think persons are tied to one user at a time and my suggestion would be to have a global set of persons and then make them visible to all users based on what photos they are allowed to access. No one should see persons of photos they are not allowed to access ofc.

It will imply creating very complicated permission system, that will require a lot of dev resources. For now it really would be better to have at least local processing (for face recognition, tags etc) for each user for all available assets (partner's included) because it's sounds as an issue or a bug.

But collaborated tags, account groups for albums collaborations, shared spaces, talkings about S3 - it all sounds like a distinct feature requests (not an issues), and it makes this thread way to much to comprehend, especially from devs perspective. I think it would be great to split this thread on different topics and focus on most significant limitations right now. You just can't do everything at once.

@Zvirovyi commented on GitHub (Jan 20, 2025): > I meant that more in a technical way under the hood. The behavior right now makes me think persons are tied to one user at a time and my suggestion would be to have a global set of persons and then make them visible to all users based on what photos they are allowed to access. No one should see persons of photos they are not allowed to access ofc. It will imply creating very complicated permission system, that will require a lot of dev resources. For now it really would be better to have at least local processing (for face recognition, tags etc) for each user for all available assets (partner's included) because it's sounds as an issue or a bug. But collaborated tags, account groups for albums collaborations, shared spaces, talkings about S3 - **it all sounds like a distinct feature requests (not an issues), and it makes this thread way to much to comprehend, especially from devs perspective**. I think it would be great to split this thread on different topics and focus on most significant limitations right now. You just can't do everything at once.

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Jan 20, 2025):

We the devs made this consolidated thread deliberately to encompass a large permissions/access rework. If some things are still not covered after that all blows over, separate threads can be made for those at that point.

@bo0tzz commented on GitHub (Jan 20, 2025): We the devs made this consolidated thread deliberately to encompass a large permissions/access rework. If some things are still not covered after that all blows over, separate threads can be made for those at that point.

deekerman commented

Author

Owner

@Meimax commented on GitHub (Jan 21, 2025):

I would like to have the same features for album sharing. Concretely I’m missing the ability to include shared albums in the timeline and searching for persons in them.

@Meimax commented on GitHub (Jan 21, 2025): I would like to have the same features for album sharing. Concretely I’m missing the ability to include shared albums in the timeline and searching for persons in them.

deekerman commented

Author

Owner

@CapSel commented on GitHub (Jan 21, 2025):

A functionality I'd like to ask for is kind of related to sharing. My immich instance is already exposed to the internet. What I (actually my wife) would like to have is ability to create links to photos of certain resolutions. This would allow me to paste a link to small photo on some forums (like phpbb). Similar what flickr does.

@CapSel commented on GitHub (Jan 21, 2025): A functionality I'd like to ask for is kind of related to sharing. My immich instance is already exposed to the internet. What I (actually my wife) would like to have is ability to create links to photos of certain resolutions. This would allow me to paste a link to small photo on some forums (like phpbb). Similar what flickr does.

deekerman commented

Author

Owner

@Zvirovyi commented on GitHub (Jan 21, 2025):

@bo0tzz Makes sense, okay 👍

@Zvirovyi commented on GitHub (Jan 21, 2025): @bo0tzz Makes sense, okay 👍

deekerman commented

2026-02-20 02:16:32 -05:00

Author

Owner

@devdan commented on GitHub (Feb 9, 2025):

This would be much appreciates.
Currently, it also seems not to be possible to use search via location or faces with shared albums. Is this correct?

@devdan commented on GitHub (Feb 9, 2025): This would be much appreciates. Currently, it also seems not to be possible to use search via location or faces with shared albums. Is this correct?

deekerman commented

Author

Owner

@Rubyer77 commented on GitHub (Feb 13, 2025):

What I need is:

User A creates an External Library and scans it
User A grants read-only access to this External Library to User B
User B can browse the library and select images to add to his personal Favorites

@Rubyer77 commented on GitHub (Feb 13, 2025): What I need is: - User A creates an External Library and scans it - User A grants read-only access to this External Library to User B - User B can browse the library and select images to add to his personal Favorites

deekerman commented

2026-02-20 02:16:32 -05:00

Author

Owner

@4goodluck commented on GitHub (Feb 14, 2025):

My use case of my wife and myself (kids are older) appears to be satisfied only by using a single user for both of us. I'm planning a conversion now. Most or all of the issues mentioned above seem to me to come down to separate (per user) meta data. Defining people tends to require a lot of work so sharing that work makes sense but any work like tags, albums, etc. become search vectors that tend toward more value and interest when shared. I recognize there are security and permission issues around all of this.

My son runs his own immich instance. So beyond all of the above I can already easily see tremendous opportunity in 'federation' between immich instances. If i look just at my siblings and other family plus friends who are family there is tremendous OPPORTUNITY to provide experiences, features and function far beyond the existing offers. I don't want to derail this conversation but keeping a wider perspective while getting all of the above right might be very helpful.

A few capabilities I didn't notice above:

Easy way to flag/tag photos to share where sharing default is not shared (kids, family, friends have lots to share but i'm sure lots to keep private or that are of less interest)
Example of easy to flag/tag - all pictures containing list of people get shared (if certain family members are in the picture good to share)
If meta data stays per user a way to share that data as well so that search of any type can span all visible assets (already covered i think but maybe generalized)
Simple high level read only or read/write permission when defining sharing

I leave off with the thought that just within this discussion there is a vast opportunity to transcend well beyond replacement of existing cloud offers.

@4goodluck commented on GitHub (Feb 14, 2025): My use case of my wife and myself (kids are older) appears to be satisfied only by using a single user for both of us. I'm planning a conversion now. Most or all of the issues mentioned above seem to me to come down to separate (per user) meta data. Defining people tends to require a lot of work so sharing that work makes sense but any work like tags, albums, etc. become search vectors that tend toward more value and interest when shared. I recognize there are security and permission issues around all of this. My son runs his own immich instance. So beyond all of the above I can already easily see tremendous opportunity in 'federation' between immich instances. If i look just at my siblings and other family plus friends who are family there is tremendous OPPORTUNITY to provide experiences, features and function far beyond the existing offers. I don't want to derail this conversation but keeping a wider perspective while getting all of the above right might be very helpful. A few capabilities I didn't notice above: - Easy way to flag/tag photos to share where sharing default is not shared (kids, family, friends have lots to share but i'm sure lots to keep private or that are of less interest) - Example of easy to flag/tag - all pictures containing list of people get shared (if certain family members are in the picture good to share) - If meta data stays per user a way to share that data as well so that search of any type can span all visible assets (already covered i think but maybe generalized) - Simple high level read only or read/write permission when defining sharing I leave off with the thought that just within this discussion there is a vast opportunity to transcend well beyond replacement of existing cloud offers.

deekerman commented

2026-02-20 02:16:32 -05:00

Author

Owner

@theemanofsteele commented on GitHub (Feb 20, 2025):

+1 for many of these suggestions. I am absolutely loving Immich and not looking back. Having the idea of "view only" users would just take that to the next level.

My use case would be targeted around sharing with users that have permissions controlled granularly. I don't want them to be able to upload photos or delete photos. But I do want them to be able to add tags, see and tag faces, create albums and assign existing photos to said albums. And maybe even be able to "cordon off" an area of photos using paths. So like photos/family are visible to all but photos/personal are visible only to me or who I choose. I get that granular permissions opens a can of worms but it could solve a lot of what's being asked.

Are there any branches or forks where folks have started down the path of building some of the ideas in this thread?

Thanks! Again, love the app. Keep up the great work.

@theemanofsteele commented on GitHub (Feb 20, 2025): +1 for many of these suggestions. I am absolutely loving Immich and not looking back. Having the idea of "view only" users would just take that to the next level. My use case would be targeted around sharing with users that have permissions controlled granularly. I don't want them to be able to upload photos or delete photos. But I do want them to be able to add tags, see and tag faces, create albums and assign existing photos to said albums. And maybe even be able to "cordon off" an area of photos using paths. So like `photos/family` are visible to all but `photos/personal` are visible only to me or who I choose. I get that granular permissions opens a can of worms but it could solve a lot of what's being asked. Are there any branches or forks where folks have started down the path of building some of the ideas in this thread? Thanks! Again, love the app. Keep up the great work.

deekerman commented

Author

Owner

@jamminuesa commented on GitHub (Mar 4, 2025):

+1 to be able to see the face and people information in a photo with all the people that can see this photo.

Also I do not know if possible but all the pictures that are shared with a user, should appear in the timeline view of that user.
I have the following set up. All of my photos are added via external libraries because it is easier for me to organize them and do back ups.
And I have parents, wife, other relatives so most of my photos are shared via album because shared profile does not make sense. Old pictures from my father's relatives that my mother's does not really need to see and viceversa. Photos with previous girlfriends that my wife doesn't really need to see and I don't want to delete because they are from trips with friends.

Hope to see changes in this matter soon enough.

Thank you for the amazing work you are doing.

@jamminuesa commented on GitHub (Mar 4, 2025): +1 to be able to see the face and people information in a photo with all the people that can see this photo. Also I do not know if possible but **all the pictures that are shared** with a user, **should appear** in the **timeline** view of that user. I have the following set up. All of my photos are added via external libraries because it is easier for me to organize them and do back ups. And I have parents, wife, other relatives so most of my photos are shared via album because shared profile does not make sense. Old pictures from my father's relatives that my mother's does not really need to see and viceversa. Photos with previous girlfriends that my wife doesn't really need to see and I don't want to delete because they are from trips with friends. Hope to see changes in this matter soon enough. Thank you for the amazing work you are doing.

deekerman commented

Author

Owner

@gaffneyd4 commented on GitHub (Mar 5, 2025):

+1 to having the option to share all albums through the partner sharing feature. Based on the comments on this issue I think I am going to back track on having multiple users on my immich instance and instead just have a single user so that I can easily collaborate on the library with my partner without having to do extra configuration.

Big thank you to all the contributors on this product, what an incredible application!

@gaffneyd4 commented on GitHub (Mar 5, 2025): +1 to having the option to share all albums through the partner sharing feature. Based on the comments on this issue I think I am going to back track on having multiple users on my immich instance and instead just have a single user so that I can easily collaborate on the library with my partner without having to do extra configuration. Big thank you to all the contributors on this product, what an incredible application!

deekerman commented

Author

Owner

@rovo89 commented on GitHub (Mar 6, 2025):

For a family which wants to share almost everything, like albums, recognized faces, favorites etc., using a single user seems to be the way to go. But I'm wondering if there would be a middle ground for those who want to keep a few things separated, like administration rights, comments or some info who took the pic.

I'm thinking of a virtual user ID which could be used e.g. as owner of albums and face mappings, thus keeping the data structures the same. And both partners would be mapped to the same virtual ID before inserting or querying, for those areas that should be shared. Theoretically, there a user could have multiple (secondary) virtual IDs, similar to Unix groups, but that's where it would get more complicated again...

@rovo89 commented on GitHub (Mar 6, 2025): For a family which wants to share almost everything, like albums, recognized faces, favorites etc., using a single user seems to be the way to go. But I'm wondering if there would be a middle ground for those who want to keep a few things separated, like administration rights, comments or some info who took the pic. I'm thinking of a virtual user ID which could be used e.g. as owner of albums and face mappings, thus keeping the data structures the same. And both partners would be mapped to the same virtual ID before inserting or querying, for those areas that should be shared. Theoretically, there a user could have multiple (secondary) virtual IDs, similar to Unix groups, but that's where it would get more complicated again...

deekerman commented

Author

Owner

@Gnorrk commented on GitHub (Mar 11, 2025):

In the current state, for the whole family to have access to all photos and data, everyone has to use one account. In this scenario, there are not enough (1) tags for who took the photo and (2) notifications that new photos have been added.
(1) If it is still difficult to add a "family mode" to immich, maybe you can add the ability for each user to tag their devices with names that would be displayed in the photo captions? Then photos from my phone would be captioned "magnificent-me" and my wife's phone would upload photos with the caption "the-best-wife-in-the-world" And all this in one account with full access to all data.
(2) At first glance, it seems stupid to notify me that I have added photos. But when several people work under one user, this is the only way to find out about new photos. Perhaps you can make a switch in the menu "make notifications about all added photos"?

@Gnorrk commented on GitHub (Mar 11, 2025): In the current state, for the whole family to have access to all photos and data, everyone has to use one account. In this scenario, there are not enough (1) tags for who took the photo and (2) notifications that new photos have been added. (1) If it is still difficult to add a "family mode" to immich, maybe you can add the ability for each user to tag their devices with names that would be displayed in the photo captions? Then photos from my phone would be captioned "magnificent-me" and my wife's phone would upload photos with the caption "the-best-wife-in-the-world" And all this in one account with full access to all data. (2) At first glance, it seems stupid to notify me that I have added photos. But when several people work under one user, this is the only way to find out about new photos. Perhaps you can make a switch in the menu "make notifications about all added photos"?

deekerman commented

Author

Owner

@Benny-Git commented on GitHub (Mar 15, 2025):

I dove into Immich some months ago to finally bring structure and searchability to our large family photo library. Immich seemed like the logical choice, and I'm still very happy with how it works. After a lot of manual work naming recognized people, cleaning up photos with incorrect metadata, trying to remove or stack duplicates, ... I finally set up SSO for Immich and created an account for my wife to be able to browse the gallery on her own. Well, of course she was greeted with a seemingly empty Immich instance. So I learnt about partner sharing, and finally got her to see our (external library) photos. This made her happy, and I thought this would just be a wonderful path forward.

Some days ago, she asked me why she can't search for people like I do. And that's when I learnt that partner sharing does not include people. ☹

Reading a lot of issues, discussions and reddit posts I now know that most people use shared accounts to achieve this, which is just a very bad anti-pattern in my opinion. Looking at the discussions, I feel that Immich's permissions system was built around the idea of hosting an Immich instance for lots of loosely connected people, where everyone would host their own backed up pictures. For that usecase, features like quotas (I don't care about those), shared albums (I don't need them right now), and others make sense. But when starting with Immich I hadn't expected my usecase (share photos with my wife and maybe later with the kids) would be too far away from the default usecase, that some essentials wouldn't work out.

Now, I don't want to move away from Immich after having invested a lot of time into it already and still seeing it as the great software it is. But I also don't want to employ nasty hacks (account sharing 😨 ) or duplicate work (mapping peoples' names again) to make it fit my usecase.

So maybe the Immich devs first need to decide on which usecases are actually in scope, and then decide how the data model needs rework to fit those usecases? Not sure whether there is a way the community can help with that?

@Benny-Git commented on GitHub (Mar 15, 2025): I dove into Immich some months ago to finally bring structure and searchability to our large family photo library. Immich seemed like the logical choice, and I'm still very happy with how it works. After a lot of manual work naming recognized people, cleaning up photos with incorrect metadata, trying to remove or stack duplicates, ... I finally set up SSO for Immich and created an account for my wife to be able to browse the gallery on her own. Well, of course she was greeted with a seemingly empty Immich instance. So I learnt about partner sharing, and finally got her to see our (external library) photos. This made her happy, and I thought this would just be a wonderful path forward. Some days ago, she asked me why she can't search for people like I do. And that's when I learnt that partner sharing does not include people. ☹ Reading a lot of issues, discussions and reddit posts I now know that most people use shared accounts to achieve this, which is just a very bad anti-pattern in my opinion. Looking at the discussions, I feel that Immich's permissions system was built around the idea of hosting an Immich instance for lots of loosely connected people, where everyone would host their own backed up pictures. For that usecase, features like quotas (I don't care about those), shared albums (I don't need them right now), and others make sense. But when starting with Immich I hadn't expected _my_ usecase (share photos with my wife and maybe later with the kids) would be too far away from the default usecase, that some essentials wouldn't work out. Now, I don't want to move away from Immich after having invested a lot of time into it already and still seeing it as the great software it is. But I also don't want to employ nasty hacks (account sharing 😨 ) or duplicate work (mapping peoples' names again) to make it fit my usecase. So maybe the Immich devs first need to decide on which usecases are actually in scope, and then decide how the data model needs rework to fit those usecases? Not sure whether there is a way the community can help with that?

deekerman commented

Author

Owner

@lagset commented on GitHub (Mar 15, 2025):

@Benny-Git well said.

Just my 5 cents on this:
I am currently using Synology Photos, but am taking a look at immich as well, since it's foss + looks very decent (props to the devs).

It is interesting for me to see, that Synology Photos' UX is suffering from very similar sharing concept (shared albums are possible, but sharing meta data like identified people, subjects, seeing shared photos in one's own timeline or map). Which is the main reason I am looking for an alternative.

Sharing in Synology Photos isn't possible in a way that makes sense for IMHO one of most typical use cases for this kind of software: Sharing (a subset) of photos, albums and meta data (people, likes, comments) with your dear ones which you trust. Unless you make use of a feature called "shared space" which introduces other unintuitive and intransparent issues for your close ones (which are not necessarily interested in mastering sharing concepts of a software).

Getting this right obviously is a tricky task since it diverges from typical (business focused) sharing and permission paradigms in software.

However, it would make this software stand out very positively in opposition to its direct competitors (like synology photos).

@lagset commented on GitHub (Mar 15, 2025): @Benny-Git well said. Just my 5 cents on this: I am currently using Synology Photos, but am taking a look at immich as well, since it's foss + looks very decent (props to the devs). It is interesting for me to see, that Synology Photos' UX is suffering from very similar sharing concept (shared albums are possible, but sharing meta data like identified people, subjects, seeing shared photos in one's own timeline or map). Which is **the main reason** I am looking for an alternative. Sharing in Synology Photos isn't possible in a way that makes sense for IMHO one of most typical use cases for this kind of software: Sharing (a subset) of photos, albums and meta data (people, likes, comments) with your dear ones which you trust. Unless you make use of a feature called "shared space" which introduces other unintuitive and intransparent issues for your close ones (which are not necessarily interested in mastering sharing concepts of a software). Getting this right obviously is a tricky task since it diverges from typical (business focused) sharing and permission paradigms in software. However, it would make this software stand out very positively in opposition to its direct competitors (like synology photos).

deekerman commented

Author

Owner

@DevonMark commented on GitHub (Mar 17, 2025):

Sharing is counterintuitive at the moment. Let's say I create a shared album, France 2024 for the family pictures. We all add pictures to it. Then my partner sees a picture of, say, a nice Chateau that I have taken, and wants to share it publically to a friend. She can download the image and then send it off, but she can't share by clicking the share button (it produces an error: no asset.share access). She can share an image she has taken but has to click into the image to see the device it has been taken with before she can see if it can be shared (and the share button is still at the top of the page, indicating it can be shared - only when clicking do you realise it is not possible).

Everything else about Immich I love. It has been a breeze setting it up. I've configured external access and even though the images are coming through Cloudflare from my local server via a rural 4g internet connection, it is faster than Google or Onedrive. But the sharing... Fix the sharing (searching in shared albums and image management) and the app becomes near perfect!

@DevonMark commented on GitHub (Mar 17, 2025): Sharing is counterintuitive at the moment. Let's say I create a shared album, France 2024 for the family pictures. We all add pictures to it. Then my partner sees a picture of, say, a nice Chateau that _I have taken_, and wants to share it publically to a friend. She can download the image and then send it off, but she can't share by clicking the share button (it produces an error: no asset.share access). She can share an image _she has taken_ but has to click into the image to see the device it has been taken with before she can see if it can be shared (and the share button is still at the top of the page, indicating it can be shared - only when clicking do you realise it is not possible). Everything else about Immich I love. It has been a breeze setting it up. I've configured external access and even though the images are coming through Cloudflare from my local server via a rural 4g internet connection, it is faster than Google or Onedrive. But the sharing... Fix the sharing (searching in shared albums and image management) and the app becomes near perfect!

deekerman commented

Author

Owner

@trentor00 commented on GitHub (Mar 19, 2025):

I, for example, can't change to Immich for this reason. It's essential to be able to share all the metadata.

@trentor00 commented on GitHub (Mar 19, 2025): I, for example, can't change to Immich for this reason. It's essential to be able to share all the metadata.

deekerman commented

Author

Owner

@burntoc commented on GitHub (Mar 30, 2025):

I understand this is apparently a difficult refactor, but I imagine this is one of the top 5 biggest barriers to adoption for an absolute ton of people. I mean, this is absolutely the issue that will have to be addressed before I jump in beyond testing in -RO mode and donate, and there's a ton of others. Yet this doesn't seem to be like a top5 priority, which is really odd.

@burntoc commented on GitHub (Mar 30, 2025): I understand this is apparently a difficult refactor, but I imagine this is one of the top 5 biggest barriers to adoption for an absolute ton of people. I mean, this is absolutely the issue that will have to be addressed before I jump in beyond testing in -RO mode and donate, and there's a ton of others. Yet this doesn't seem to be like a top5 priority, which is really odd.

deekerman commented

Author

Owner

@alextran1502 commented on GitHub (Mar 30, 2025):

Our priorities at the moment are

Stable release
Stable release
Stable release
Stable release
Stable release
Rework on assets ownership

😁

@alextran1502 commented on GitHub (Mar 30, 2025): Our priorities at the moment are 1. Stable release 2. Stable release 3. Stable release 4. Stable release 5. Stable release 6. Rework on assets ownership 😁

deekerman commented

Author

Owner

@gaffneyd4 commented on GitHub (Mar 30, 2025):

I'm sure if anyone wants to influence the priorities of the maintainers a healthy donation might be the best place to start. Otherwise contribute some code or 👍 the issue 😁

@gaffneyd4 commented on GitHub (Mar 30, 2025): I'm sure if anyone wants to influence the priorities of the maintainers a healthy donation might be the best place to start. Otherwise contribute some code or 👍 the issue 😁

deekerman commented

Author

Owner

@PiAir commented on GitHub (Mar 31, 2025):

I'm sure if anyone wants to influence the priorities of the maintainers a healthy donation might be the best place to start. Otherwise contribute some code or 👍 the issue 😁

You were probably thinking about a healthier donation than 'just' a server license. But I was guessing it's a start and did that. I tried Immich in free mode for 3 months and am impressed by the number of updates and improvements. It made me disable Synology Photo and just use Immich with external libraries. The completer partner sharing feature (including people recognition) would be very much appreciated, but I'll wait. 👍

@PiAir commented on GitHub (Mar 31, 2025): > I'm sure if anyone wants to influence the priorities of the maintainers a healthy donation might be the best place to start. Otherwise contribute some code or 👍 the issue 😁 You were probably thinking about a healthier donation than 'just' a server license. But I was guessing it's a start and did that. I tried Immich in free mode for 3 months and am impressed by the number of updates and improvements. It made me disable Synology Photo and just use Immich with external libraries. The completer partner sharing feature (including people recognition) would be very much appreciated, but I'll wait. 👍

deekerman commented

Author

Owner

@stefanks commented on GitHub (Apr 4, 2025):

Curious if the ability to configure a user with upload only permissions, i.e. no modifications/deletions is a part of this feature? I'd like my phone to be only able to write and not delete photos.

Should this be a separately tracked issue, or it might make sense to consider it as a part of this one?

@stefanks commented on GitHub (Apr 4, 2025): Curious if the ability to configure a user with upload only permissions, i.e. no modifications/deletions is a part of this feature? I'd like my phone to be only able to write and not delete photos. Should this be a separately tracked issue, or it might make sense to consider it as a part of this one?

deekerman commented

Author

Owner

@dmalapsh commented on GitHub (Apr 6, 2025):

I also like the idea of a shared space that only includes photos that the user has marked themselves. With this approach, I think automation will also be useful. For example, I would like the photos on which the person is marked to automatically fall into our common space with him.

@dmalapsh commented on GitHub (Apr 6, 2025): I also like the idea of a shared space that only includes photos that the user has marked themselves. With this approach, I think automation will also be useful. For example, I would like the photos on which the person is marked to automatically fall into our common space with him.

deekerman commented

Author

Owner

@charles-997 commented on GitHub (Apr 11, 2025):

shared space that only includes photos that the user has marked themselves

In my view, it would be ideal if this shared space was agnostic to the file path of the images.

In other words, I'd like to be able to designate photos to "contribute to the shared space" regardless of if those photos are in my primary immich library or an external library.

@charles-997 commented on GitHub (Apr 11, 2025): > shared space that only includes photos that the user has marked themselves In my view, it would be ideal if this shared space was agnostic to the file path of the images. In other words, I'd like to be able to designate photos to "contribute to the shared space" regardless of if those photos are in my primary immich library or an external library.

deekerman commented

Author

Owner

@PHTremor commented on GitHub (Apr 16, 2025):

Sharing precious photos and videos is an important part of immich, but right now it is a bit confusing and limiting. There are some technical implications to sharing decisions, especially as it relates to security and access controls. Lately there have been a lot of PRs tweaking queries here and there, but really this deserves a proper face lift by the development team. For now, we are going to put a feature freeze on any sharing related changes while we internally discuss and come up with a plan for what sharing in immich will look like moving forward.

This issue will serve as a placeholder for current limitations and feature requests around various sharing mechanisms

A "better solution" should incorporate following:

Albums

Stacks

Shared links

Partner sharing

Library sharing

Asset data (tags, people, etc.)

Actions in the web that are "sharing aware", which includes better error messages, more clarity around what actions can be done on what assets, etc.

I agree with the sharing of Asset Data. For my use case, I wanted to use Immich for a Non-Profit to easily manage and find images. This would mean, for Partner sharing and Shared Albums, all users from the organisation can search images across the shared resources using the same Asset Data (tags, people, etc).

I've tried a few workarounds, but they would eventually break on future updates, which might be costly for the NGO. I don't like Piwigo for its UI and lack of support for Docker deployment; PhotoPrism's Freemium model is a red flag; LibrePhotos is not as active as Immich. I love Immich, and these Features will be awesome to have @alextran1502 and all contributors.

@PHTremor commented on GitHub (Apr 16, 2025): > Sharing precious photos and videos is an important part of immich, but right now it is a bit confusing and limiting. There are some technical implications to sharing decisions, especially as it relates to security and access controls. Lately there have been a lot of PRs tweaking queries here and there, but really this deserves a proper face lift by the development team. For now, we are going to put a feature freeze on any sharing related changes while we internally discuss and come up with a plan for what sharing in immich will look like moving forward. > > This issue will serve as a placeholder for current limitations and feature requests around various sharing mechanisms > > A "better solution" should incorporate following: > > * Albums > * Stacks > * Shared links > * Partner sharing > * Library sharing > * Asset data (tags, people, etc.) > * Actions in the web that are "sharing aware", which includes better error messages, more clarity around what actions can be done on what assets, etc. I agree with the sharing of Asset Data. For my use case, I wanted to use Immich for a Non-Profit to easily manage and find images. This would mean, for Partner sharing and Shared Albums, all users from the organisation can search images across the shared resources using the same Asset Data (tags, people, etc). I've tried a few workarounds, but they would eventually break on future updates, which might be costly for the NGO. I don't like Piwigo for its UI and lack of support for Docker deployment; PhotoPrism's Freemium model is a red flag; LibrePhotos is not as active as Immich. I love Immich, and these Features will be awesome to have @alextran1502 and all contributors.

deekerman commented

Author

Owner

@shadowjig commented on GitHub (Apr 22, 2025):

Please consider adding nested album support in conjunction with this sharing request. Because it would be great to share a top level album and have all sub albums, photos, and assets shared along with it.

@shadowjig commented on GitHub (Apr 22, 2025): Please consider adding nested album support in conjunction with this sharing request. Because it would be great to share a top level album and have all sub albums, photos, and assets shared along with it.

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Apr 23, 2025):

@shadowjig that is entirely unrelated to this thread.

@bo0tzz commented on GitHub (Apr 23, 2025): @shadowjig that is entirely unrelated to this thread.

deekerman commented

Author

Owner

@shadowjig commented on GitHub (Apr 23, 2025):

@shadowjig that is entirely unrelated to this thread.

It's unrelated in content.

But I would maintain it's technically relevant that the structure of the storage whether logically or physically is related to sharing.

@shadowjig commented on GitHub (Apr 23, 2025): > @shadowjig that is entirely unrelated to this thread. It's unrelated in content. But I would maintain it's technically relevant that the structure of the storage whether logically or physically is related to sharing.

deekerman commented

Author

Owner

@frohlfing commented on GitHub (Apr 24, 2025):

I have named all my people, which took a lot of time. To spare my wife, who also has an account, the effort, I built a small python script that matches my named people to her unnamed people using face embeddings. The script simply adopts the name with a suffix "?" so she can see that the name was assigned automatically. To see what is being matched, you can also pass the --preview option. This will display the matches without making any changes in Immich.

Perhaps this could be an idea to implement as a task in Immich without having to modify existing structures.

import argparse
import psycopg2
import json
import math
import matplotlib.pyplot as plt
import matplotlib as mpl
import numpy as np
import os
from dotenv import load_dotenv
from PIL import Image
from matplotlib.patches import Rectangle
from sklearn.metrics.pairwise import cosine_similarity

load_dotenv()
DB_HOST = os.getenv("DB_HOST")  # siehe portainer > Containers > immich_postgres / Connected Networks
DB_PASSWORD = os.getenv("DB_PASSWORD", "postgres")  # siehe portainer > Containers > immich_postgres / ENV
UPLOAD_PATH = os.getenv("UPLOAD_PATH", "/data/compose/1/library")  # siehe portainer > Containers > Volumes

def load_named_faces(conn, email: str) -> dict|None:
    """
    Lädt alle benannten Gesichter (Name und Embeddings) eines Benutzers.
    Rückgabe: {name: [embedding, ...]}
    """
    cur = conn.cursor()
    try:
        cur.execute("""
            SELECT p.name, fs.embedding
            FROM person AS p
            INNER JOIN users AS u ON u.id = p."ownerId"
            INNER JOIN asset_faces AS af ON af."personId" = p.id
            INNER JOIN face_search AS fs ON fs."faceId" = af.id
            WHERE u.email = %s AND p.name <> ''
            """, (email,)
        )
        people = {}
        for name, emb in cur.fetchall():
            arr = np.array(json.loads(emb), dtype=np.float32)
            people.setdefault(name, []).append(arr)
    finally:
        cur.close()
    return people

def load_unnamed_faces(conn, email: str) -> dict|None:
    """
    Lädt alle unbenannten Gesichter (Person-ID, Embeddings, Asset-Path, Bild-Ausschnitt) eines Benutzers.
    Rückgabe: {person_id: [{embedding, path, bounding}, ...]}
    """
    cur = conn.cursor()
    try:
        cur.execute("""
            SELECT p.id, fs.embedding, f.path, af."boundingBoxX1", af."boundingBoxY1", af."boundingBoxX2", af."boundingBoxY2"
            FROM person AS p
            INNER JOIN users AS u ON u.id = p."ownerId"
            INNER JOIN asset_faces AS af ON af.id = p."faceAssetId"
            INNER JOIN asset_files AS f ON f."assetId" = af."assetId" AND f.type = 'preview'
            INNER JOIN asset_faces AS af2 ON af2."personId" = p.id
            INNER JOIN face_search AS fs ON fs."faceId" = af2.id
            WHERE u.email = %s AND p.name = ''
            """, (email,)
        )
        people = {}
        for pid, emb, path, x1, y1, x2, y2 in cur.fetchall():
            arr = np.array(json.loads(emb), dtype=np.float32)
            entry = {'pid': pid, 'embedding': arr, 'path': path, 'bounding': (x1, y1, x2, y2)}
            people.setdefault(pid, []).append(entry)
    finally:
        cur.close()
    return people

def find_best_matches(a_persons: dict, b_persons: dict, threshold: float) -> list:
    """
    Findet die besten Übereinstimmung der Personen basierend auf Face Embeddings
    Gibt eine Liste der Treffer zurück: [(pid, name, score, path, bounding)]
    """
    matches = []
    a_embeddings = {name: np.vstack(vecs) for name, vecs in a_persons.items()}
    for pid, b_entries in b_persons.items():
        b_mean_vector = np.mean([e['embedding'] for e in b_entries], axis=0).reshape(1, -1)
        best_name, best_score = None, 0.0
        for name, a_vectors in a_embeddings.items():
            score = np.mean(cosine_similarity(b_mean_vector, a_vectors))  # durchschnitt der Cosine Similarity zwischen zwei Embedding-Sets
            if score > best_score:
                best_name, best_score = name, score
        if best_score >= threshold:
            matches.append((pid, best_name, float(best_score), b_entries[0]['path'], b_entries[0]['bounding']))
    return matches

def show_matches(matches: list) -> None:
    """
    Zeigt alle Treffer in einem Gitter-Layout an.
    Für jede Person wird ein Bild mit Rahmen um das Gesicht angezeigt.
    """
    # Bildschirmgröße (in Zoll) bestimmen
    backend = mpl.get_backend()
    try:
        if "inline" in backend:
            screen_width, screen_height = 15, 8  # Fallback für Notebook
        else:
            import tkinter as tk
            root = tk.Tk()
            screen_width = root.winfo_screenwidth() / root.winfo_fpixels('1i')
            screen_height = root.winfo_screenheight() / root.winfo_fpixels('1i')
            root.destroy()
    except Exception:
        screen_width, screen_height = 15, 8  # Fallback-Werte

    # Dynamische Spaltenanzahl berechnen (min. 2, max. 6)
    n = len(matches)
    cols = max(2, min(6, int(screen_width // 5)))
    rows = math.ceil(n / cols)

    # Subplots anlegen
    fig, axes = plt.subplots(rows, cols, figsize=(cols * 5, rows * 5))
    axes = axes.flatten()

    # Achsen außerhalb des Bereichs ausblenden
    for ax in axes[n:]:
        ax.axis('off')

    # Bilder und Titel zeichnen
    for idx, (_pid, name, score, path, bounding) in enumerate(matches):
        path = path.replace("upload", UPLOAD_PATH)
        ax = axes[idx]
        ax.axis('off')
        # Bild
        if os.path.exists(path):
            try:
                img = Image.open(path)
                ax.imshow(img)
            except Exception as e:
                ax.text(0.5, 0.5, f"Fehler beim Laden:\n{e}", ha='center', va='center')
            x1, y1, x2, y2 = bounding
            rect = Rectangle((x1, y1), x2 - x1, y2 - y1, linewidth=2, edgecolor='red', facecolor='none')
            ax.add_patch(rect)
        else:
            ax.text(0.5, 0.5, f"Bild nicht gefunden:\n{path}", ha='center', va='center', wrap=True)
        # Titel oberhalb der Axes platzieren
        ax.set_title(f"{name} ({score:.2f})", fontsize=12)

    # Abstand zwischen den Subplots erhöhen
    plt.subplots_adjust(hspace=2, wspace=0.6)
    plt.tight_layout(pad=3)
    plt.show()

def update_db(conn, matches: list, used_names: list, suffix: str) -> None:
    """
    Übernimmt die Namen der erkannten Personen
    """
    cur = conn.cursor()
    try:
        for pid, name, _score, _path, _bounding in matches:
            name = name + suffix
            unique_name = name
            i = 1
            while unique_name in used_names:
                i += 1
                unique_name = f"{name} ({i})"
            cur.execute("UPDATE person SET name = %s WHERE id = %s and name = ''", (unique_name, pid))
            used_names.append(unique_name)
        conn.commit()
    finally:
        cur.close()

def main():
    parser = argparse.ArgumentParser(description="Immich - Personenabgleich")
    parser.add_argument('email1', type=str, help='E-Mail Benutzer A (benannte Personen)')
    parser.add_argument('email2', type=str, help='E-Mail Benutzer B (unbenannte Personen)')
    parser.add_argument('-t', '--threshold', type=float, default=0.5, help='Schwellenwert für Cosine Similarity zw. 0 und 1 (Default: 0.5)')
    parser.add_argument('-p', '--preview', action='store_true', help='Nur Vorschau anzeigen, nicht automatisch benennen')
    parser.add_argument('-s', '--suffix', type=str, default='?', help='Suffix für automatisch zugeordnete Namen (Default: "?"')
    args = parser.parse_args()

    print(f"Baue Datenbankverbindung mit {DB_HOST}:5432 auf... ", end="")
    conn = psycopg2.connect(dbname="immich", user="postgres", password=DB_PASSWORD, host=DB_HOST, port="5432")
    print("ok")

    # Lade Daten
    a_known = load_named_faces(conn, args.email1)
    print(f"Benutzer {args.email1} hat {len(a_known)} bekannte Personen.")
    b_known = list(load_named_faces(conn, args.email2).keys())
    b_unknown = load_unnamed_faces(conn, args.email2)
    print(f"Benutzer {args.email2} hat insgesamt {len(b_known) + len(b_unknown)} Personen. Davon sind {len(b_unknown)} ohne Namen.")

    # Übereinstimmungen finden
    matches = find_best_matches(a_known, b_unknown, args.threshold)
    print(f"Es wurden {len(matches)} Personen mit bisher unbekannten Namen erkannt.")

    if args.preview:
        show_matches(matches)
    else:
        if args.suffix:
            print(f"Die Namen werden mit Suffix \"{args.suffix}\" eingetragen... ", end="")
        else:
            print("Die Namen werden eingetragen... ", end="")
        update_db(conn, matches, b_known, args.suffix)
        print("ok")

    conn.close()

if __name__ == "__main__":
    main()

@frohlfing commented on GitHub (Apr 24, 2025): I have named all my people, which took a lot of time. To spare my wife, who also has an account, the effort, I built a small python script that matches my named people to her unnamed people using face embeddings. The script simply adopts the name with a suffix "?" so she can see that the name was assigned automatically. To see what is being matched, you can also pass the --preview option. This will display the matches without making any changes in Immich. Perhaps this could be an idea to implement as a task in Immich without having to modify existing structures. ------------------------------------- <pre> import argparse import psycopg2 import json import math import matplotlib.pyplot as plt import matplotlib as mpl import numpy as np import os from dotenv import load_dotenv from PIL import Image from matplotlib.patches import Rectangle from sklearn.metrics.pairwise import cosine_similarity load_dotenv() DB_HOST = os.getenv("DB_HOST") # siehe portainer > Containers > immich_postgres / Connected Networks DB_PASSWORD = os.getenv("DB_PASSWORD", "postgres") # siehe portainer > Containers > immich_postgres / ENV UPLOAD_PATH = os.getenv("UPLOAD_PATH", "/data/compose/1/library") # siehe portainer > Containers > Volumes def load_named_faces(conn, email: str) -> dict|None: """ Lädt alle benannten Gesichter (Name und Embeddings) eines Benutzers. Rückgabe: {name: [embedding, ...]} """ cur = conn.cursor() try: cur.execute(""" SELECT p.name, fs.embedding FROM person AS p INNER JOIN users AS u ON u.id = p."ownerId" INNER JOIN asset_faces AS af ON af."personId" = p.id INNER JOIN face_search AS fs ON fs."faceId" = af.id WHERE u.email = %s AND p.name <> '' """, (email,) ) people = {} for name, emb in cur.fetchall(): arr = np.array(json.loads(emb), dtype=np.float32) people.setdefault(name, []).append(arr) finally: cur.close() return people def load_unnamed_faces(conn, email: str) -> dict|None: """ Lädt alle unbenannten Gesichter (Person-ID, Embeddings, Asset-Path, Bild-Ausschnitt) eines Benutzers. Rückgabe: {person_id: [{embedding, path, bounding}, ...]} """ cur = conn.cursor() try: cur.execute(""" SELECT p.id, fs.embedding, f.path, af."boundingBoxX1", af."boundingBoxY1", af."boundingBoxX2", af."boundingBoxY2" FROM person AS p INNER JOIN users AS u ON u.id = p."ownerId" INNER JOIN asset_faces AS af ON af.id = p."faceAssetId" INNER JOIN asset_files AS f ON f."assetId" = af."assetId" AND f.type = 'preview' INNER JOIN asset_faces AS af2 ON af2."personId" = p.id INNER JOIN face_search AS fs ON fs."faceId" = af2.id WHERE u.email = %s AND p.name = '' """, (email,) ) people = {} for pid, emb, path, x1, y1, x2, y2 in cur.fetchall(): arr = np.array(json.loads(emb), dtype=np.float32) entry = {'pid': pid, 'embedding': arr, 'path': path, 'bounding': (x1, y1, x2, y2)} people.setdefault(pid, []).append(entry) finally: cur.close() return people def find_best_matches(a_persons: dict, b_persons: dict, threshold: float) -> list: """ Findet die besten Übereinstimmung der Personen basierend auf Face Embeddings Gibt eine Liste der Treffer zurück: [(pid, name, score, path, bounding)] """ matches = [] a_embeddings = {name: np.vstack(vecs) for name, vecs in a_persons.items()} for pid, b_entries in b_persons.items(): b_mean_vector = np.mean([e['embedding'] for e in b_entries], axis=0).reshape(1, -1) best_name, best_score = None, 0.0 for name, a_vectors in a_embeddings.items(): score = np.mean(cosine_similarity(b_mean_vector, a_vectors)) # durchschnitt der Cosine Similarity zwischen zwei Embedding-Sets if score > best_score: best_name, best_score = name, score if best_score >= threshold: matches.append((pid, best_name, float(best_score), b_entries[0]['path'], b_entries[0]['bounding'])) return matches def show_matches(matches: list) -> None: """ Zeigt alle Treffer in einem Gitter-Layout an. Für jede Person wird ein Bild mit Rahmen um das Gesicht angezeigt. """ # Bildschirmgröße (in Zoll) bestimmen backend = mpl.get_backend() try: if "inline" in backend: screen_width, screen_height = 15, 8 # Fallback für Notebook else: import tkinter as tk root = tk.Tk() screen_width = root.winfo_screenwidth() / root.winfo_fpixels('1i') screen_height = root.winfo_screenheight() / root.winfo_fpixels('1i') root.destroy() except Exception: screen_width, screen_height = 15, 8 # Fallback-Werte # Dynamische Spaltenanzahl berechnen (min. 2, max. 6) n = len(matches) cols = max(2, min(6, int(screen_width // 5))) rows = math.ceil(n / cols) # Subplots anlegen fig, axes = plt.subplots(rows, cols, figsize=(cols * 5, rows * 5)) axes = axes.flatten() # Achsen außerhalb des Bereichs ausblenden for ax in axes[n:]: ax.axis('off') # Bilder und Titel zeichnen for idx, (_pid, name, score, path, bounding) in enumerate(matches): path = path.replace("upload", UPLOAD_PATH) ax = axes[idx] ax.axis('off') # Bild if os.path.exists(path): try: img = Image.open(path) ax.imshow(img) except Exception as e: ax.text(0.5, 0.5, f"Fehler beim Laden:\n{e}", ha='center', va='center') x1, y1, x2, y2 = bounding rect = Rectangle((x1, y1), x2 - x1, y2 - y1, linewidth=2, edgecolor='red', facecolor='none') ax.add_patch(rect) else: ax.text(0.5, 0.5, f"Bild nicht gefunden:\n{path}", ha='center', va='center', wrap=True) # Titel oberhalb der Axes platzieren ax.set_title(f"{name} ({score:.2f})", fontsize=12) # Abstand zwischen den Subplots erhöhen plt.subplots_adjust(hspace=2, wspace=0.6) plt.tight_layout(pad=3) plt.show() def update_db(conn, matches: list, used_names: list, suffix: str) -> None: """ Übernimmt die Namen der erkannten Personen """ cur = conn.cursor() try: for pid, name, _score, _path, _bounding in matches: name = name + suffix unique_name = name i = 1 while unique_name in used_names: i += 1 unique_name = f"{name} ({i})" cur.execute("UPDATE person SET name = %s WHERE id = %s and name = ''", (unique_name, pid)) used_names.append(unique_name) conn.commit() finally: cur.close() def main(): parser = argparse.ArgumentParser(description="Immich - Personenabgleich") parser.add_argument('email1', type=str, help='E-Mail Benutzer A (benannte Personen)') parser.add_argument('email2', type=str, help='E-Mail Benutzer B (unbenannte Personen)') parser.add_argument('-t', '--threshold', type=float, default=0.5, help='Schwellenwert für Cosine Similarity zw. 0 und 1 (Default: 0.5)') parser.add_argument('-p', '--preview', action='store_true', help='Nur Vorschau anzeigen, nicht automatisch benennen') parser.add_argument('-s', '--suffix', type=str, default='?', help='Suffix für automatisch zugeordnete Namen (Default: "?"') args = parser.parse_args() print(f"Baue Datenbankverbindung mit {DB_HOST}:5432 auf... ", end="") conn = psycopg2.connect(dbname="immich", user="postgres", password=DB_PASSWORD, host=DB_HOST, port="5432") print("ok") # Lade Daten a_known = load_named_faces(conn, args.email1) print(f"Benutzer {args.email1} hat {len(a_known)} bekannte Personen.") b_known = list(load_named_faces(conn, args.email2).keys()) b_unknown = load_unnamed_faces(conn, args.email2) print(f"Benutzer {args.email2} hat insgesamt {len(b_known) + len(b_unknown)} Personen. Davon sind {len(b_unknown)} ohne Namen.") # Übereinstimmungen finden matches = find_best_matches(a_known, b_unknown, args.threshold) print(f"Es wurden {len(matches)} Personen mit bisher unbekannten Namen erkannt.") if args.preview: show_matches(matches) else: if args.suffix: print(f"Die Namen werden mit Suffix \"{args.suffix}\" eingetragen... ", end="") else: print("Die Namen werden eingetragen... ", end="") update_db(conn, matches, b_known, args.suffix) print("ok") conn.close() if __name__ == "__main__": main() </pre>

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Apr 24, 2025):

That should come with a warning that mucking around in the database is unsupported and risks breaking things.

@bo0tzz commented on GitHub (Apr 24, 2025): That should come with a warning that mucking around in the database is unsupported and risks breaking things.

deekerman commented

Author

Owner

@DonRichie commented on GitHub (May 2, 2025):

I feel like this is the best place to ask:
Please provide meta information for thumbnails and maybe other data on every sharable website.

It should be something like:

<meta property="og:title" content="Title" />
<meta property="og:site_name" content="Site name"/>
<meta property="og:description" content="Description" />
<meta property="og:image" content="Link to your thumbnail" />

Especially providing the thumbnail is interesting, because I am right now sharing albums with others and there is no beautiful image displayed when doing so in a messenger like telegram.

EDIT for the google users:
My issue was that I didn't set an externalDomain in immich-config.json. Now the thumbnail works as expected.

@DonRichie commented on GitHub (May 2, 2025): I feel like this is the best place to ask: Please provide meta information for thumbnails and maybe other data on every sharable website. It should be something like: ``` <meta property="og:title" content="Title" /> <meta property="og:site_name" content="Site name"/> <meta property="og:description" content="Description" /> <meta property="og:image" content="Link to your thumbnail" /> ``` Especially providing the thumbnail is interesting, because I am right now sharing albums with others and there is no beautiful image displayed when doing so in a messenger like telegram. **EDIT for the google users: My issue was that I didn't set an externalDomain in immich-config.json. Now the thumbnail works as expected.**

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (May 3, 2025):

@DonRichie no, that's off-topic for this thread. We already set og tags on shared links, if that's not working for you please open a Q&A discussion.

@bo0tzz commented on GitHub (May 3, 2025): @DonRichie no, that's off-topic for this thread. We already set `og` tags on shared links, if that's not working for you please open a Q&A discussion.

deekerman commented

2026-02-20 02:16:37 -05:00

Author

Owner

@pricci1 commented on GitHub (May 5, 2025):

Let me share my current approach, which is tailored for my use-case.
I use Immich to collect family photos (e.g. family trips, special events) and as a "backup" for each family member to use for their private photos.

The key is that the Admin account owns all family assets (photos/videos) and albums.
The Admin account shares its complete library with all the other accounts.
If a user creates an album and shares it with the Admin, the album's ownership is transferred to the Admin.
If a user adds an asset to an admin-owned album, the asset ownership is transferred to the admin.
TODO: On asset ownership transfer, add a comment with the original owner's account to keep track.

To achieve that, I added a bit of code (that does not change the db schema) to the server, which you can see here.

@pricci1 commented on GitHub (May 5, 2025): Let me share my current approach, which is tailored for my use-case. I use Immich to collect family photos (e.g. family trips, special events) and as a "backup" for each family member to use for their private photos. The key is that the Admin account owns all family assets (photos/videos) and albums. The Admin account [shares its complete library](https://immich.app/docs/features/partner-sharing) with all the other accounts. If a user creates an album and shares it with the Admin, the album's ownership is transferred to the Admin. If a user adds an asset to an admin-owned album, the asset ownership is transferred to the admin. TODO: On asset ownership transfer, add a comment with the original owner's account to keep track. To achieve that, I added a bit of code (that does not change the db schema) to the server, which you can see [here](https://github.com/immich-app/immich/compare/main...pricci1:immich:92be42205fbeaf9ba6bb70fcccc97cf61a0c0d94).

deekerman commented

Author

Owner

@mthxx commented on GitHub (May 7, 2025):

I'd like throw my support in for this feature, specifically the sharing of asset data (facial data syncing between partner sharing and shared albums). I am currently migrating from Apple Photos to Immich and plan to purchase the license to support the project once I've finished migrating both of our libraries over. But the lack of facial data syncing as part of partner or album sharing is likely going to force my partner and I to use a single shared user on Immich. Something I'd rather avoid doing since we really just want to share photo's related to our family and events.

@mthxx commented on GitHub (May 7, 2025): I'd like throw my support in for this feature, specifically the sharing of asset data (facial data syncing between partner sharing and shared albums). I am currently migrating from Apple Photos to Immich and plan to purchase the license to support the project once I've finished migrating both of our libraries over. But the lack of facial data syncing as part of partner or album sharing is likely going to force my partner and I to use a single shared user on Immich. Something I'd rather avoid doing since we really just want to share photo's related to our family and events.

deekerman commented

2026-02-20 02:16:37 -05:00

Author

Owner

@josiah-eichelman commented on GitHub (May 13, 2025):

I'd like to add my support for this issue. Specifically I think you should be able to add any image you can see in a shared album to another album even if the original photo is not yours.

I think this is the intuitive behavior - if I can see an image in an album I may want to re-organize it by putting it another album

@josiah-eichelman commented on GitHub (May 13, 2025): I'd like to add my support for this issue. Specifically I think you should be able to add any image you can see in a shared album to another album even if the original photo is not yours. I think this is the intuitive behavior - if I can see an image in an album I may want to re-organize it by putting it another album

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (May 13, 2025):

To clarify; there is no need to 'support' this issue, we will definitely be implementing this at some point.

@bo0tzz commented on GitHub (May 13, 2025): To clarify; there is no need to 'support' this issue, we will definitely be implementing this at some point.

deekerman commented

Author

Owner

@shadowjig commented on GitHub (May 13, 2025):

@bo0tzz I'm glad to hear about the feature being considered for implementation. How can we help you and the development team?

@shadowjig commented on GitHub (May 13, 2025): @bo0tzz I'm glad to hear about the feature being considered for implementation. How can we help you and the development team?

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (May 13, 2025):

It's a complex rework that will need lots of consideration and discussion, so there's not really anything that anyone outside of the team can do.

@bo0tzz commented on GitHub (May 13, 2025): It's a complex rework that will need lots of consideration and discussion, so there's not really anything that anyone outside of the team can do.

deekerman commented

Author

Owner

@Hekmat8 commented on GitHub (May 23, 2025):

Let me share my current approach, which is tailored for my use-case. I use Immich to collect family photos (e.g. family trips, special events) and as a "backup" for each family member to use for their private photos.

The key is that the Admin account owns all family assets (photos/videos) and albums. The Admin account shares its complete library with all the other accounts. If a user creates an album and shares it with the Admin, the album's ownership is transferred to the Admin. If a user adds an asset to an admin-owned album, the asset ownership is transferred to the admin. TODO: On asset ownership transfer, add a comment with the original owner's account to keep track.

To achieve that, I added a bit of code (that does not change the db schema) to the server, which you can see here.

Looks like a great option. A bit of noob in the Immich world. Can you give some more details on the solution (apart from changing index.ts and creating the 2 new files. How do you go about using those functions in Immich.

@Hekmat8 commented on GitHub (May 23, 2025): > Let me share my current approach, which is tailored for my use-case. I use Immich to collect family photos (e.g. family trips, special events) and as a "backup" for each family member to use for their private photos. > > The key is that the Admin account owns all family assets (photos/videos) and albums. The Admin account [shares its complete library](https://immich.app/docs/features/partner-sharing) with all the other accounts. If a user creates an album and shares it with the Admin, the album's ownership is transferred to the Admin. If a user adds an asset to an admin-owned album, the asset ownership is transferred to the admin. TODO: On asset ownership transfer, add a comment with the original owner's account to keep track. > > To achieve that, I added a bit of code (that does not change the db schema) to the server, which you can see [here](https://github.com/immich-app/immich/compare/main...pricci1:immich:92be42205fbeaf9ba6bb70fcccc97cf61a0c0d94). Looks like a great option. A bit of noob in the Immich world. Can you give some more details on the solution (apart from changing index.ts and creating the 2 new files. How do you go about using those functions in Immich.

deekerman commented

2026-02-20 02:16:39 -05:00

Author

Owner

@itskagee commented on GitHub (May 24, 2025):

+1 for many of these suggestions. I am absolutely loving Immich and not looking back. Having the idea of "view only" users would just take that to the next level.

My use case would be targeted around sharing with users that have permissions controlled granularly. I don't want them to be able to upload photos or delete photos. But I do want them to be able to add tags, see and tag faces, create albums and assign existing photos to said albums. And maybe even be able to "cordon off" an area of photos using paths. So like photos/family are visible to all but photos/personal are visible only to me or who I choose. I get that granular permissions opens a can of worms but it could solve a lot of what's being asked.

Are there any branches or forks where folks have started down the path of building some of the ideas in this thread?

Thanks! Again, love the app. Keep up the great work.

I think view-only, no-upload users are now possible after the PR that enabled 0GB accounts.
I just tested it out and it allows a user to see shared media and albums, but not upload anywhere.
Not sure about the other features though like tagging, creating albums, re-assigning photos etc. Did not test those.

In a similar fashion, I too had a suggestion regarding shared albums.
I would like users to be able to upload to shared albums, but not to their private Immich space.

The reason for this is, suppose I go on a trip with some friends, and I want to create a public shared album with them where we can all share our photos.
While this is possible right now by sharing an album publicly, it has 2 drawbacks:

Sharing is done via links. If a person wants to look at the album later, they have to find the link again, or have me re-share it.
It is only protected with a password. And that password has to be shared / searched for again as well. This is rather unsafe and cumbersome.

Ideally I would want them as users in my instance, as that way both these problems are solved.
But the issue with that is, they can upload additional media to their private space as well, which I don't want them to do.

Now if I only wanted them to view photos to shared albums and not upload anything, then that is solved using 0GB accounts as I mentioned above. But the problem arises when they have some photos to upload as well.

I could think of two solutions to this problem:

There exists a special set of users (or user permissions) that permit access and uploads to shared albums, but not to the private space.
Uploads to shared albums use sharer's quota, not the uploader's.
Currently, it is the opposite.
If this were changed, then I could have these users be 0GB accounts so they won't be able to upload anything anyway, and for shared albums, whatever they upload ends up under my quota (or owned by my user, whatever seems feasible; although this comes with its own host of problems).

If someone has any better solutions for this problem, then please share them as well!

@itskagee commented on GitHub (May 24, 2025): > +1 for many of these suggestions. I am absolutely loving Immich and not looking back. Having the idea of "view only" users would just take that to the next level. > > My use case would be targeted around sharing with users that have permissions controlled granularly. I don't want them to be able to upload photos or delete photos. But I do want them to be able to add tags, see and tag faces, create albums and assign existing photos to said albums. And maybe even be able to "cordon off" an area of photos using paths. So like `photos/family` are visible to all but `photos/personal` are visible only to me or who I choose. I get that granular permissions opens a can of worms but it could solve a lot of what's being asked. > > Are there any branches or forks where folks have started down the path of building some of the ideas in this thread? > > Thanks! Again, love the app. Keep up the great work. I think view-only, no-upload users are now possible after the PR that enabled 0GB accounts. I just tested it out and it allows a user to see shared media and albums, but not upload anywhere. Not sure about the other features though like tagging, creating albums, re-assigning photos etc. Did not test those. In a similar fashion, I too had a suggestion regarding shared albums. I would like users to be able to upload to shared albums, but not to their private Immich space. The reason for this is, suppose I go on a trip with some friends, and I want to create a public shared album with them where we can all share our photos. While this is possible right now by sharing an album publicly, it has 2 drawbacks: - Sharing is done via links. If a person wants to look at the album later, they have to find the link again, or have me re-share it. - It is only protected with a password. And that password has to be shared / searched for again as well. This is rather unsafe and cumbersome. Ideally I would want them as users in my instance, as that way both these problems are solved. But the issue with that is, they can upload additional media to their private space as well, which I don't want them to do. Now if I only wanted them to view photos to shared albums and not upload anything, then that is solved using 0GB accounts as I mentioned above. But the problem arises when they have some photos to upload as well. I could think of two solutions to this problem: 1. There exists a special set of users (or user permissions) that permit access and uploads to shared albums, but not to the private space. 2. Uploads to shared albums use sharer's quota, not the uploader's. Currently, it is the opposite. If this were changed, then I could have these users be 0GB accounts so they won't be able to upload anything anyway, and for shared albums, whatever they upload ends up under my quota (or owned by my user, whatever seems feasible; although this comes with its own host of problems). If someone has any better solutions for this problem, then please share them as well!

deekerman commented

Author

Owner

@kevincox commented on GitHub (May 26, 2025):

I'm in a similar boat. One of the pain points right now is the facial data sharing. For me and my partner the ideal solution would be to fully share all facial recognition data. However another option could be that when a photo is shared with me a second pass of facial recognition is run in the context of my account. Because while sharing the work to name and group faces into people would be great, the biggest pain is that if I search for a person I only get half of the results because the other half are in my partner's account, even though I can see these photos in my timeline.

@kevincox commented on GitHub (May 26, 2025): I'm in a similar boat. One of the pain points right now is the facial data sharing. For me and my partner the ideal solution would be to fully share all facial recognition data. However another option could be that when a photo is shared with me a **second** pass of facial recognition is run in the context of my account. Because while sharing the work to name and group faces into people would be great, the biggest pain is that if I search for a person I only get half of the results because the other half are in my partner's account, even though I can see these photos in my timeline.

deekerman commented

2026-02-20 02:16:39 -05:00

Author

Owner

@kevincox commented on GitHub (May 26, 2025):

Another related issue is that it would be nice to be able to view people in (publicly) shared albums. For example I have shared albums of events and I have tagged people. It would be nice if all of the viewers could see the names for example if they missed someone's name during the event. Extra-extra nice would be searching for that face (or really any sort of search) within the public album. For example if someone wanted to download all photos of them self from the album. This would probably fall more into the feature of picking what metadata to share in a shared album than general sharing between accounts.

Although this has a potential negative interaction with the previous suggestion. If someone shares an album with me including the people and Immich processes these images with my own set of people, which results are shown? The album owners, mine or both?

@kevincox commented on GitHub (May 26, 2025): Another related issue is that it would be nice to be able to view people in (publicly) shared albums. For example I have shared albums of events and I have tagged people. It would be nice if all of the viewers could see the names for example if they missed someone's name during the event. Extra-extra nice would be searching for that face (or really any sort of search) within the public album. For example if someone wanted to download all photos of them self from the album. This would probably fall more into the feature of picking what metadata to share in a shared album than general sharing between accounts. Although this has a potential negative interaction with the previous suggestion. If someone shares an album with me including the people and Immich processes these images with my own set of people, which results are shown? The album owners, mine or both?

deekerman commented

2026-02-20 02:16:39 -05:00

Author

Owner

@headtr1ck commented on GitHub (Jun 1, 2025):

Would you mind pinning this issue so it is easier to find?

@headtr1ck commented on GitHub (Jun 1, 2025): Would you mind pinning this issue so it is easier to find?

deekerman commented

Author

Owner

@carlosjfcasero commented on GitHub (Jun 6, 2025):

Maybe a good idea would be creating "groups" and allowing those groups to have assets, external libraries, albums etc., so that they don't belong to a user but to all the group. That's the approach most of the sharing content tools follow

@carlosjfcasero commented on GitHub (Jun 6, 2025): Maybe a good idea would be creating "groups" and allowing those groups to have assets, external libraries, albums etc., so that they don't belong to a user but to all the group. That's the approach most of the sharing content tools follow

deekerman commented

Author

Owner

@hthrkuh commented on GitHub (Jun 7, 2025):

Able to share tags with shared albums include search like i did here #19000

@hthrkuh commented on GitHub (Jun 7, 2025): Able to share tags with shared albums include search like i did here #19000

deekerman commented

Author

Owner

@bverkron commented on GitHub (Jun 8, 2025):

Maybe a good idea would be creating "groups" and allowing those groups to have assets, external libraries, albums etc., so that they don't belong to a user but to all the group. That's the approach most of the sharing content tools follow

I think it is extremely important to consider this as part of the solution. Managing permissions via groups (or RBAC) has many, many advantages over managing individual user permissions which can become unwieldy and confusing / complicated before long.

Really hope we can manage permissions via groups when this is reworked.

Also want to throw in a quick comment about my use case for improved sharing. My wife and have 3 kids and thousands of photos of them to share with extended family. While we are both currently sharing an account so we can get the same level of access to people info, modifications, etc I do not want to follow that same (poor) pattern with extended family such as our parents (kids grand parents), aunts/uncles, etc. Some of them are tech savy enough to not mess with things but others definitely are not and it's much too over reaching to give extended family access to our main shared "workaround" account. I'm currently reluctantly still using the Adobe share galleries and would absolutely love to abandon those in favour of Immich sharing.

@bverkron commented on GitHub (Jun 8, 2025): > Maybe a good idea would be creating "groups" and allowing those groups to have assets, external libraries, albums etc., so that they don't belong to a user but to all the group. That's the approach most of the sharing content tools follow I think it is extremely important to consider this as part of the solution. Managing permissions via groups (or RBAC) has many, many advantages over managing individual user permissions which can become unwieldy and confusing / complicated before long. Really hope we can manage permissions via groups when this is reworked. Also want to throw in a quick comment about my use case for improved sharing. My wife and have 3 kids and thousands of photos of them to share with extended family. While we are both currently sharing an account so we can get the same level of access to people info, modifications, etc I do not want to follow that same (poor) pattern with extended family such as our parents (kids grand parents), aunts/uncles, etc. Some of them are tech savy enough to not mess with things but others definitely are not and it's much too over reaching to give extended family access to our main shared "workaround" account. I'm currently reluctantly still using the Adobe share galleries and would absolutely love to abandon those in favour of Immich sharing.

deekerman commented

Author

Owner

@jan-leila commented on GitHub (Jun 9, 2025):

Wanted to add a note here that with now sharing works right now via sharing albums any photos that are in the locked folder can't be shared with other people, so photos that you may want to share with your partner but have hidden behind a pin in case your kid gets a hold of your phone have to be manually and independently managed between both accounts

@jan-leila commented on GitHub (Jun 9, 2025): Wanted to add a note here that with now sharing works right now via sharing albums any photos that are in the locked folder can't be shared with other people, so photos that you may want to share with your partner but have hidden behind a pin in case your kid gets a hold of your phone have to be manually and independently managed between both accounts

deekerman commented

Author

Owner

@Tofu66 commented on GitHub (Jun 11, 2025):

I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-)

I was also thinking of the ability to share (directly) only a subset of photos to a partner's timeline without creating new albums or links. Detailed feature request #19037.

@Tofu66 commented on GitHub (Jun 11, 2025): > I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-) I was also thinking of the ability to share (directly) only a subset of photos to a partner's timeline without creating new albums or links. Detailed feature request #19037.

deekerman commented

Author

Owner

@hthrkuh commented on GitHub (Jun 11, 2025):

I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-)

I was also thinking of the ability to share (directly) only a subset of photos to a partner's timeline without creating new albums or links. Detailed feature request #19037.

About that i think tags share is the best solution, and for now i added feature that able to share tags , but for now its works only when you do album share #19000

@hthrkuh commented on GitHub (Jun 11, 2025): > > I am also coming from Synology Photos, and looking for an alternative. Immich is looking pretty good! It would be nice if there was a way to only share a subset of photos with my partner, for example I don't want to share boring work photos. But I also don't want to use albums, it is annoying to have to define albums for everything :-) > > I was also thinking of the ability to share (directly) only a subset of photos to a partner's timeline without creating new albums or links. Detailed feature request [#19037](https://github.com/immich-app/immich/discussions/19037). About that i think tags share is the best solution, and for now i added feature that able to share tags , but for now its works only when you do album share #19000

deekerman commented

Author

Owner

@lucius-the commented on GitHub (Jun 18, 2025):

I'd like to point out that Immich is probably being considered primarily by home users. That means: me, wife, kids and couple of other family members as users. I believe this to be a quite common / prevalent scenario for Immich.

For that use case a feature that enables any user to tag some person and all other users being able to use that tag on their images - is pretty much expected. You know: one server - one family, so shared metadata, people, tags, etc.

Unless project owner considers Immich primarily as a hosted service, that is to be used by completely unrelated people (which is a different use case altogether) the current implementation, where I spend hours tagging people only to find that my wife can't see or use those tags - is a quite a bit of a miss.

That being said, in case you really want to support the option of using Immich as a hosted service for many unrelated users, why not provide an option: "use shared people/tags" or "use per-user people/tags", something we could configure per server instance. I believe most Immich users would default to the first option, we'd all like to share people tags inside a family. Besides, for half of the kids in the pictures only my kids can tell who's who ;) so they'd tag those and we'd tag the grownups.

I was actually expecting that to work out of the box and was quite surprised that is doesn't work that way.

@lucius-the commented on GitHub (Jun 18, 2025): I'd like to point out that Immich is probably being considered primarily by home users. That means: me, wife, kids and couple of other family members as users. I believe this to be a quite common / prevalent scenario for Immich. For that use case a feature that enables any user to tag some person and all other users being able to use that tag on their images - is pretty much expected. You know: one server - one family, so shared metadata, people, tags, etc. Unless project owner considers Immich primarily as a hosted service, that is to be used by completely unrelated people (which is a different use case altogether) the current implementation, where I spend hours tagging people only to find that my wife can't see or use those tags - is a quite a bit of a miss. That being said, in case you really want to support the option of using Immich as a hosted service for many unrelated users, why not provide an option: "use shared people/tags" or "use per-user people/tags", something we could configure per server instance. I believe most Immich users would default to the first option, we'd all like to share people tags inside a family. Besides, for half of the kids in the pictures only my kids can tell who's who ;) so they'd tag those and we'd tag the grownups. I was actually expecting that to work out of the box and was quite surprised that is doesn't work that way.

deekerman commented

Author

Owner

@Bananas-Are-Yellow commented on GitHub (Jun 18, 2025):

I don't know if this is unhelpful, but this thread seems to cover the grand unified theory of collaborative albums, sharing and tagging, when I just want something quite simple.

I create an album and I share a link with family or friends. That works fine, but if ever they want to find that album again, they have to find the link I sent them, typically by email or WhatsApp. I can see my own albums listed as a gallery, with a title and cover photo for each one, so that's what I want my family or friends to have too. I don't want them to contribute more photos, or tag anything, I just want them to be able to see a gallery of albums I've shared with them, so they can view them at any time.

I guess there should be "shared publicly" (no need for an account) and "shared with user" (user needs to log in), but in my case, I just want "shared publicly".

@Bananas-Are-Yellow commented on GitHub (Jun 18, 2025): I don't know if this is unhelpful, but this thread seems to cover the grand unified theory of collaborative albums, sharing and tagging, when I just want something quite simple. I create an album and I share a link with family or friends. That works fine, but if ever they want to find that album again, they have to find the link I sent them, typically by email or WhatsApp. I can see my own albums listed as a gallery, with a title and cover photo for each one, so that's what I want my family or friends to have too. I don't want them to contribute more photos, or tag anything, I just want them to be able to see a gallery of albums I've shared with them, so they can view them at any time. I guess there should be "shared publicly" (no need for an account) and "shared with user" (user needs to log in), but in my case, I just want "shared publicly".

deekerman commented

Author

Owner

@itskagee commented on GitHub (Jun 18, 2025):

I don't know if this is unhelpful, but this thread seems to cover the grand unified theory of collaborative albums, sharing and tagging, when I just want something quite simple.

I create an album and I share a link with family or friends. That works fine, but if ever they want to find that album again, they have to find the link I sent them, typically by email or WhatsApp. I can see my own albums listed as a gallery, with a title and cover photo for each one, so that's what I want my family or friends to have too. I don't want them to contribute more photos, or tag anything, I just want them to be able to see a gallery of albums I've shared with them, so they can view them at any time.

I guess there should be "shared publicly" (no need for an account) and "shared with user" (user needs to log in), but in my case, I just want "shared publicly".

0GB accounts should work for you.

Create a 0GB account for friends/family for whom you want view-only access, then share the album with that user and they should be able to view it as you do but not upload anything.

You cannot have albums being shown in the app for individuals without making an account for them though. Since there is no way for Immich to track who that particular user would be and what they would see in that case.

You can also share publicly using links (like you're doing now), but that only allows individual media/albums, not a combination of albums. Is that what you're looking for?

@itskagee commented on GitHub (Jun 18, 2025): > I don't know if this is unhelpful, but this thread seems to cover the grand unified theory of collaborative albums, sharing and tagging, when I just want something quite simple. > > I create an album and I share a link with family or friends. That works fine, but if ever they want to find that album again, they have to find the link I sent them, typically by email or WhatsApp. I can see my own albums listed as a gallery, with a title and cover photo for each one, so that's what I want my family or friends to have too. I don't want them to contribute more photos, or tag anything, I just want them to be able to see a gallery of albums I've shared with them, so they can view them at any time. > > I guess there should be "shared publicly" (no need for an account) and "shared with user" (user needs to log in), but in my case, I just want "shared publicly". 0GB accounts should work for you. Create a 0GB account for friends/family for whom you want view-only access, then share the album with that user and they should be able to view it as you do but not upload anything. You cannot have albums being shown in the app for individuals without making an account for them though. Since there is no way for Immich to track who that particular user would be and what they would see in that case. You can also share publicly using links (like you're doing now), but that only allows individual media/albums, not a combination of albums. Is that what you're looking for?

deekerman commented

Author

Owner

@Bananas-Are-Yellow commented on GitHub (Jun 19, 2025):

It sounds like what I'm looking for. I will try that out. Thanks.

@Bananas-Are-Yellow commented on GitHub (Jun 19, 2025): It sounds like what I'm looking for. I will try that out. Thanks.

deekerman commented

Author

Owner

@fabien4455 commented on GitHub (Jun 20, 2025):

I installed Immich today. The solution is ALMOST perfect for me. I use it to share pictures for my family.

I discovered the face recognition on my account and found it really accurate. I want my family to have this feature on the albums I share to them.

Right now, when they click on "Information", they just can't see it. Also, in search tab on the app, persons won't appear.

I would love to see this feature implemented, where we can share person recognition to users so they can use it as a filter to view pictures...

@fabien4455 commented on GitHub (Jun 20, 2025): I installed Immich today. The solution is ALMOST perfect for me. I use it to share pictures for my family. I discovered the face recognition on my account and found it really accurate. I want my family to have this feature on the albums I share to them. Right now, when they click on "Information", they just can't see it. Also, in search tab on the app, persons won't appear. I would love to see this feature implemented, where we can share person recognition to users so they can use it as a filter to view pictures...

deekerman commented

Author

Owner

@fabien4455 commented on GitHub (Jun 20, 2025):

I would pay to have this feature implemented. Is this in a roadmap somewhere ?

@fabien4455 commented on GitHub (Jun 20, 2025): I would pay to have this feature implemented. Is this in a roadmap somewhere ?

deekerman commented

Author

Owner

@dc911x commented on GitHub (Jun 20, 2025):

I would pay to have this feature implemented. Is this in a roadmap somewhere ?

You can't "pay for a feature" but you can ofc support them by:

Buying a licence -> https://buy.immich.app/
Buying merch -> https://immich.store/

And you can view the roadmap here: https://immich.app/roadmap/

@dc911x commented on GitHub (Jun 20, 2025): > I would pay to have this feature implemented. Is this in a roadmap somewhere ? You can't "pay for a feature" but you can ofc support them by: 1. Buying a licence -> https://buy.immich.app/ 2. Buying merch -> https://immich.store/ And you can view the roadmap here: https://immich.app/roadmap/

deekerman commented

Author

Owner

@Dacesilian commented on GitHub (Jun 23, 2025):

Looking into roadmap, I don't see this issue planned, but I see (from my point of view) not so much important features like "basic editor" or "workflows". I hope this being considered and will be done, some time. It would be great and then we all can migrate from Google Photos. Issue that immich can't really search using text input is understandable. But face recognition across family is needed. Thank you.

@Dacesilian commented on GitHub (Jun 23, 2025): Looking into roadmap, I don't see this issue planned, but I see (from my point of view) not so much important features like "basic editor" or "workflows". I hope this being considered and will be done, some time. It would be great and then we all can migrate from Google Photos. Issue that immich can't really search using text input is understandable. But face recognition across family is needed. Thank you.

deekerman commented

Author

Owner

@bo0tzz commented on GitHub (Jun 23, 2025):

The roadmap is just major features, not every odd thing we're planning to do.

@bo0tzz commented on GitHub (Jun 23, 2025): The roadmap is just major features, not every odd thing we're planning to do.

deekerman commented

Author

Owner

@fabien4455 commented on GitHub (Jun 23, 2025):

My only workaround that I found is to create a specific user for my family and share the account for everyone. This is not secure but for now it does the job...

@fabien4455 commented on GitHub (Jun 23, 2025): My only workaround that I found is to create a specific user for my family and share the account for everyone. This is not secure but for now it does the job...

deekerman commented

Author

Owner

@JasonLocklin commented on GitHub (Jun 25, 2025):

Sharing asset tags is actually 2 parts, one of which is super important and easier, the other is less important and hard to accomplish correctly. Sharing the actual tag names between users is complicated because of privacy and personalization of names of people, places, etc. But that's not actually the biggest headache with sharing photos.

The headache is just the human effort of supplementing the facial recognition algorithm:

Person 1 and Person 7 are the same person
Photo 35 is Person 2, not Person 5
Photos 24 through 35 of Person 6 are actually a new person.
etc.

No need for names to be shared here, but this can be hours of work -especially with children, where the algorithm tends to fail, and shouldn't need to be duplicated by every user. This is just augmenting facial recognition with human vision, so if you expose the facial recognition results to users, why not allow "crowd sourced" corrections to that algorithm too? This could be true for any Immich install, not just partners sharing pictures of their kids. Think google reCAPTCHA but for faces, within an Immich install. This could drastically improve the experience of clustering and tagging of faces in an install where multiple people are making the above manual corrections to shared albums based on their own eyes.

@JasonLocklin commented on GitHub (Jun 25, 2025): Sharing asset tags is actually 2 parts, one of which is super important and easier, the other is less important and hard to accomplish correctly. Sharing the actual tag names between users is complicated because of privacy and personalization of names of people, places, etc. But that's not actually the biggest headache with sharing photos. The headache is just the human effort of supplementing the facial recognition algorithm: - Person 1 and Person 7 are the same person - Photo 35 is Person 2, not Person 5 - Photos 24 through 35 of Person 6 are *actually* a new person. - etc. No need for names to be shared here, but this can be hours of work -especially with children, where the algorithm tends to fail, and shouldn't need to be duplicated by every user. This is just augmenting facial recognition with human vision, so if you expose the facial recognition results to users, why not allow "crowd sourced" corrections to that algorithm too? This could be true for any Immich install, not just partners sharing pictures of their kids. Think google reCAPTCHA but for faces, within an Immich install. This could drastically improve the experience of clustering and tagging of faces in an install where multiple people are making the above manual corrections to shared albums based on their own eyes.

deekerman commented

Author

Owner

@yann117 commented on GitHub (Jun 28, 2025):

The roadmap is just major features, not every odd thing we're planning to do.

But implementing a good sharing solution is definitely an utter major feature.

It is extremely important, useful and probably equivalently hard to implement. As proof, even other bigger companies/products (that one we should not name) doesn't have it!

If Immich get it, that will make it one of is kind 🥇

By the way, if we could get rid of the "Partner sharing" description, and just use "Sharing", that would be wonderful.
Life is not only about partner ... I might not have a partner, but:

parents
sisters, brothers
children
friends
hobby associations
sports clubs
...

Sharing is a 1..N relation, it is universal and applies to many different use-case.
"Partner Sharing" is just too limited and restrictive, it makes it awkward to even use it for all of the other above scenarios.

(but I truly guess what you have in mind with "better sharing" already address this)

@yann117 commented on GitHub (Jun 28, 2025): > The roadmap is just major features, not every odd thing we're planning to do. But implementing a good sharing solution is definitely an utter major feature. It is extremely important, useful and probably equivalently hard to implement. As proof, even other bigger companies/products (that one we should not name) doesn't have it! If Immich get it, that will make it one of is kind 🥇 By the way, if we could get rid of the "Partner sharing" description, and just use "Sharing", that would be wonderful. Life is not only about _partner_ ... I might not have a partner, but: - parents - sisters, brothers - children - friends - hobby associations - sports clubs - ... Sharing is a 1..N relation, it is universal and applies to many different use-case. "Partner Sharing" is just too limited and restrictive, it makes it awkward to even use it for all of the other above scenarios. (but I truly guess what you have in mind with "better sharing" already address this)

deekerman commented

Author

Owner

@MrSimmo commented on GitHub (Jul 4, 2025):

This might be useful to someone so thought I'd post it. While the dev team are looking at sharing, I wanted a solution where I could share all of my Albums with my wife so she could view the albums. Partner sharing doesn't currently support view-only sharing and also doesn't include albums; Album sharing works but for a very large library it's painful to manually share every album.

So I created a python script uses the Immich API to go through all albums and have options to do a few things:

Share with another user
Change the other users permissions from viewer to editor and vice versa
Remove sharing with that other user.

If you run the script without any arguments, it displays a simple help...

Feel free to use it as you wish, it obviously comes with no warranty blah blah...

#!/usr/bin/env` python3
"""
Bulk-share (or un-share) EVERY album you own in Immich with one user.

Examples
--------
# read-only
python3 share_all_albums.py --url https://immich/api --key KEY --user wife --role viewer
# read-write
python3 share_all_albums.py … --role editor
# revoke access
python3 share_all_albums.py … --role remove
# preview only
python3 share_all_albums.py … --dry-run
"""

import argparse, sys, requests

# ───────────────────────── CLI ──────────────────────────
def args_():
    p = argparse.ArgumentParser(description="Grant / change / revoke album access")
    p.add_argument("--url",  required=True, help="Immich base API URL, e.g. https://host/api")
    p.add_argument("--key",  required=True, help="Immich API key")
    p.add_argument("--user", required=True, help="Target username or e-mail local-part")
    p.add_argument("--role", default="viewer",
                   choices=["viewer", "editor", "remove"],
                   help="viewer | editor | remove (default viewer)")
    p.add_argument("--dry-run", action="store_true",
                   help="Show actions without changing anything")
    return p.parse_args()

# ───────────────────────── MAIN ─────────────────────────
def main():
    a   = args_()
    api = a.url.rstrip("/")

    s = requests.Session()
    s.headers.update({"x-api-key": a.key,
                      "accept": "application/json",
                      "content-type": "application/json"})

    # 1️⃣  look up user-id
    users = s.get(f"{api}/admin/users").json()
    try:
        uid = next(u["id"] for u in users
                   if u["name"].lower() == a.user.lower()
                   or u["email"].split("@")[0].lower() == a.user.lower())
    except StopIteration:
        sys.exit(f"❌  No Immich user matching “{a.user}”")
    print(f"🆔  Target user-id: {uid}")

    # 2️⃣  list albums
    albums = s.get(f"{api}/albums").json()
    print(f"📚  {len(albums)} album(s) found\n")

    # 3️⃣  process each
    errs = 0
    for alb in albums:
        aid   = alb["id"]
        title = alb.get("albumName") or "(untitled)"
        current = next((au for au in alb.get("albumUsers", [])
                        if au["user"]["id"] == uid), None)

        # ─────────── revoke ───────────
        if a.role == "remove":
            if not current:
                print(f"✔️  {title} – already not shared")
                continue
            print(f"→  {title} – revoke access")
            if a.dry_run: continue
            r = s.delete(f"{api}/albums/{aid}/user/{uid}")      # DELETE
            if r.ok: print(f"✅  {title} – access removed")
            else:    errs += 1; print(f"⚠️  {title} – failed ({r.status_code}): {r.text.strip()}")
            continue  # done with this album

        # ─────────── add / update ───────────
        desired = a.role
        if current and current["role"] == desired:
            print(f"✔️  {title} – already {desired}")
            continue

        action = "update" if current else "share"
        print(f"→  {title} – {action} as {desired}")
        if a.dry_run: continue

        if current:
            # change role
            r = s.put(f"{api}/albums/{aid}/user/{uid}", json={"role": desired})  # PUT (update) :contentReference[oaicite:2]{index=2}
        else:
            # first-time share
            payload = {"albumUsers":[{"userId": uid, "role": desired}]}
            r = s.put(f"{api}/albums/{aid}/users", json=payload)                 # PUT (add) :contentReference[oaicite:3]{index=3}

        if r.ok: print(f"✅  {title} – set to {desired}")
        else:    errs += 1; print(f"⚠️  {title} – failed ({r.status_code}): {r.text.strip()}")

    print(f"\n🏁  Finished with {errs} error(s)")

if __name__ == "__main__":
    main()

@MrSimmo commented on GitHub (Jul 4, 2025): This might be useful to someone so thought I'd post it. While the dev team are looking at sharing, I wanted a solution where I could share all of my Albums with my wife so she could view the albums. Partner sharing doesn't currently support view-only sharing and also doesn't include albums; Album sharing works but for a very large library it's painful to manually share every album. So I created a python script uses the Immich API to go through all albums and have options to do a few things: 1. Share with another user 2. Change the other users permissions from viewer to editor and vice versa 3. Remove sharing with that other user. If you run the script without any arguments, it displays a simple help... Feel free to use it as you wish, it obviously comes with no warranty blah blah... ``` #!/usr/bin/env` python3 """ Bulk-share (or un-share) EVERY album you own in Immich with one user. Examples -------- # read-only python3 share_all_albums.py --url https://immich/api --key KEY --user wife --role viewer # read-write python3 share_all_albums.py … --role editor # revoke access python3 share_all_albums.py … --role remove # preview only python3 share_all_albums.py … --dry-run """ import argparse, sys, requests # ───────────────────────── CLI ────────────────────────── def args_(): p = argparse.ArgumentParser(description="Grant / change / revoke album access") p.add_argument("--url", required=True, help="Immich base API URL, e.g. https://host/api") p.add_argument("--key", required=True, help="Immich API key") p.add_argument("--user", required=True, help="Target username or e-mail local-part") p.add_argument("--role", default="viewer", choices=["viewer", "editor", "remove"], help="viewer | editor | remove (default viewer)") p.add_argument("--dry-run", action="store_true", help="Show actions without changing anything") return p.parse_args() # ───────────────────────── MAIN ───────────────────────── def main(): a = args_() api = a.url.rstrip("/") s = requests.Session() s.headers.update({"x-api-key": a.key, "accept": "application/json", "content-type": "application/json"}) # 1️⃣ look up user-id users = s.get(f"{api}/admin/users").json() try: uid = next(u["id"] for u in users if u["name"].lower() == a.user.lower() or u["email"].split("@")[0].lower() == a.user.lower()) except StopIteration: sys.exit(f"❌ No Immich user matching “{a.user}”") print(f"🆔 Target user-id: {uid}") # 2️⃣ list albums albums = s.get(f"{api}/albums").json() print(f"📚 {len(albums)} album(s) found\n") # 3️⃣ process each errs = 0 for alb in albums: aid = alb["id"] title = alb.get("albumName") or "(untitled)" current = next((au for au in alb.get("albumUsers", []) if au["user"]["id"] == uid), None) # ─────────── revoke ─────────── if a.role == "remove": if not current: print(f"✔️ {title} – already not shared") continue print(f"→ {title} – revoke access") if a.dry_run: continue r = s.delete(f"{api}/albums/{aid}/user/{uid}") # DELETE if r.ok: print(f"✅ {title} – access removed") else: errs += 1; print(f"⚠️ {title} – failed ({r.status_code}): {r.text.strip()}") continue # done with this album # ─────────── add / update ─────────── desired = a.role if current and current["role"] == desired: print(f"✔️ {title} – already {desired}") continue action = "update" if current else "share" print(f"→ {title} – {action} as {desired}") if a.dry_run: continue if current: # change role r = s.put(f"{api}/albums/{aid}/user/{uid}", json={"role": desired}) # PUT (update) :contentReference[oaicite:2]{index=2} else: # first-time share payload = {"albumUsers":[{"userId": uid, "role": desired}]} r = s.put(f"{api}/albums/{aid}/users", json=payload) # PUT (add) :contentReference[oaicite:3]{index=3} if r.ok: print(f"✅ {title} – set to {desired}") else: errs += 1; print(f"⚠️ {title} – failed ({r.status_code}): {r.text.strip()}") print(f"\n🏁 Finished with {errs} error(s)") if __name__ == "__main__": main() ```

deekerman commented

Author

Owner

@JacksonUtsch commented on GitHub (Jul 19, 2025):

Sharing by a specific directory in external library is my vote. (being able to select multiple)

@JacksonUtsch commented on GitHub (Jul 19, 2025): Sharing by a specific directory in external library is my vote. (being able to select multiple)

deekerman commented

Author

Owner

@zilexa commented on GitHub (Aug 1, 2025):

Wow I thought I quickly scan through this request.. 30min later.

This is my summary, it looks like people all want a "Spaces" option, which is almost what Partner Sharing offers. What is requested now, within the concept of Partner Sharing:

Sharing of assets (tags, people/face recognition data).
Per-library sharing (instead of all-or-nothing, people want to have a shared library and besides that, their own private library similar to what Synology Photos offers).
External Library selectable for Partner Sharing

There are some other requests like having multiple Partner Sharing (multiple partners). But I think the above 2 or 3 capture the bulk.

Current workaround fails to capture these 3 points:

Create a 3rd account that shares everything (partner sharing) with 2 other accounts.
But none of the partners will be able to benefit from the people/face recognition data and probably also will not see each others favorites tags.

@zilexa commented on GitHub (Aug 1, 2025): Wow I thought I quickly scan through this request.. 30min later. This is my summary, it looks like people all want a "Spaces" option, which is almost what Partner Sharing offers. What is requested now, within the concept of Partner Sharing: 1. Sharing of assets (tags, people/face recognition data). 2. Per-library sharing (instead of all-or-nothing, people want to have a shared library and besides that, their own private library similar to what Synology Photos offers). 3. External Library selectable for Partner Sharing There are some other requests like having multiple Partner Sharing (multiple partners). But I think the above 2 or 3 capture the bulk. Current workaround fails to capture these 3 points: > Create a 3rd account that shares everything (partner sharing) with 2 other accounts. > But none of the partners will be able to benefit from the people/face recognition data and probably also will not see each others favorites tags.

deekerman commented

Author

Owner

@OffsetMonkey538 commented on GitHub (Aug 2, 2025):

I have albums for different family trips which I share with each user and everyone adds the photos they've made.
Currently my biggest problems are that the images don't show up in our timelines and that people can't create share links for images that were added by other people. You can select the photos and press "Share Link", but it will say "Error while creating shared link". (Also face recognition on those images would be cool, I'd even be fine with that being run on each image for every user it's shared to)

@OffsetMonkey538 commented on GitHub (Aug 2, 2025): I have albums for different family trips which I share with each user and everyone adds the photos they've made. Currently my biggest problems are that the images don't show up in our timelines and that people can't create share links for images that were added by other people. You can select the photos and press "Share Link", but it will say "Error while creating shared link". (Also face recognition on those images would be cool, I'd even be fine with that being run on each image for every user it's shared to)

deekerman commented

Author

Owner

@alice2o25 commented on GitHub (Aug 3, 2025):

I’m experiencing a limitation where videos from shared albums don’t show up in the video search for non-admin users, only in their own library. This matches the current sharing constraints noted here. With the feature freeze in place, I understand no immediate changes are planned. I’d like to confirm if this specific case (video search for shared albums) is already covered in the discussion, or if it should be considered in the planned sharing overhaul. This affects usability for users with many shared albums. Thanks for any insight!

@alice2o25 commented on GitHub (Aug 3, 2025): I’m experiencing a limitation where videos from shared albums don’t show up in the video search for non-admin users, only in their own library. This matches the current sharing constraints noted here. With the feature freeze in place, I understand no immediate changes are planned. I’d like to confirm if this specific case (video search for shared albums) is already covered in the discussion, or if it should be considered in the planned sharing overhaul. This affects usability for users with many shared albums. Thanks for any insight!

deekerman commented

Author

Owner

@itsmejoeeey commented on GitHub (Aug 3, 2025):

Sharing of assets (tags, people/face recognition data).

This is a big feature that would be big for me also.

Maybe the maintainers can answer but:

Is there any way to sponsor towards a specific feature such as this?
Is there any more detailed roadmap, and indication on where on that roadmap this feature would be?

Thank you to the maintainers for all the work you've put in to-date to make Immich such a game-changer!

@itsmejoeeey commented on GitHub (Aug 3, 2025): > > 1. Sharing of assets (tags, people/face recognition data). > This is a big feature that would be big for me also. Maybe the maintainers can answer but: - Is there any way to sponsor towards a specific feature such as this? - Is there any more detailed roadmap, and indication on where on that roadmap this feature would be? Thank you to the maintainers for all the work you've put in to-date to make Immich such a game-changer!

deekerman commented

Author

Owner

@ajamico commented on GitHub (Aug 4, 2025):

Tagged faces not sharing across users was the biggest reason why it took me so long to finally start using Immich: tagging faces in our massive (300k+) collection of photos/videos is a hobby of mine, but not feasible (nor wanted) for all the family members to do individually.

I agree with @carlosjfcasero - user groups would be super nice. I manage a DAM (MediaValet, if you're curious) for an organization, and we have different teams set up as different groups, so they can have a shared space within their team but not see other team's stuff. I'd love something like that for my family photos, and I'd want some metadata to be shared across the whole library (not siloed to groups), like people names and their facial recognition profiles. That way they could be set up/managed once without duplication of effort.

My use case is... complicated, but since people are sharing their ideal use cases here for dev consideration I thought I might as well. Here's the background: my parents are divorced, and I'm still in contact with both sides. They don't want to see the other's photos post-divorce, but me and my siblings want to see both.
Here's my pipe dream feature that I haven't been able to find in any (non-enterprise) app (maybe besides Synology Photos but I don't have one of their NASs so haven't looked too much into it):

I have two groups, GroupA and GroupB. Mom's side is assigned to GroupA, Dad's side is assigned to GroupB, and us siblings are in both GroupA and GroupB.
On upload, the uploader can set which of their groups they'd like to share the photos with. By default (maybe changeable in settings), they could choose to not share with any group, and the photo would only be visible in their private library.
That way me & my siblings' photos we choose could be seen by both groups (or just one depending on what we want), photos of the pre-divorce family could be tagged with both groups so everyone could see, and my mom's post-divorce photos wouldn't show up on my dad's family's timelines (and vice versa).
And as stated before, face recognition & names would be shared for the whole library, so that's only something that has to be done once for all users to see. (Users would only see the people that show up in photos that they have access to)

I know we can't influence which features for the dev team to focus on, but I'd happily become a sponsor + more if that use case becomes possible, especially with the quality that the team has shown thus far. <3

@ajamico commented on GitHub (Aug 4, 2025): Tagged faces not sharing across users was the biggest reason why it took me so long to finally start using Immich: tagging faces in our massive (300k+) collection of photos/videos is a hobby of mine, but not feasible (nor wanted) for all the family members to do individually. I agree with @carlosjfcasero - user groups would be super nice. I manage a DAM (MediaValet, if you're curious) for an organization, and we have different teams set up as different groups, so they can have a shared space within their team but not see other team's stuff. I'd love something like that for my family photos, and I'd want some metadata to be shared across the whole library (not siloed to groups), like people names and their facial recognition profiles. That way they could be set up/managed once without duplication of effort. My use case is... complicated, but since people are sharing their ideal use cases here for dev consideration I thought I might as well. Here's the background: my parents are divorced, and I'm still in contact with both sides. They don't want to see the other's photos post-divorce, but me and my siblings want to see both. Here's my pipe dream feature that I haven't been able to find in any (non-enterprise) app (maybe besides Synology Photos but I don't have one of their NASs so haven't looked too much into it): - I have two groups, GroupA and GroupB. Mom's side is assigned to GroupA, Dad's side is assigned to GroupB, and us siblings are in both GroupA and GroupB. - On upload, the uploader can set which of their groups they'd like to share the photos with. By default (maybe changeable in settings), they could choose to not share with any group, and the photo would only be visible in their private library. - That way me & my siblings' photos we choose could be seen by both groups (or just one depending on what we want), photos of the pre-divorce family could be tagged with both groups so everyone could see, and my mom's post-divorce photos wouldn't show up on my dad's family's timelines (and vice versa). - And as stated before, face recognition & names would be shared for the whole library, so that's only something that has to be done once for all users to see. (Users would only see the people that show up in photos that they have access to) I know we can't influence which features for the dev team to focus on, but I'd happily become a sponsor + more if that use case becomes possible, especially with the quality that the team has shown thus far. <3

deekerman commented

Author

Owner

@levifig commented on GitHub (Aug 27, 2025):

Just sharing my humble 2¢ on this…

In terms of Partner Sharing (which for me should always be viewed in a significantly different way from just "photo sharing"), I think it should always be viewed as "single creator, dual owner": if one partner deletes it, it remains shared, just moved to the trash (for both users) until it's deleted from the system (by the normal server task). Only the "creator" user can stop "partner sharing" on the photo, but every other permission is "owned" by both partners… :)

Essentially there's only one item, one metadata bundle, one of everything, but the item is "flagged" as being present in two Libraries.

I know part of the problem with this is filesystem structure, so forgive me for possibly oversimplifying everything… I sympathize with the difficulty of developing this feature, and am just sharing my thoughts after a Discord interaction about this issue…

FWIW, for the more general "media sharing", I think albums are the only (sane) way to go, with permissions being set on the album, not individual media item.

Thank you for all your work!

@levifig commented on GitHub (Aug 27, 2025): Just sharing my humble 2¢ on this… In terms of Partner Sharing (which for me should always be viewed in a significantly different way from just "photo sharing"), I think it should always be viewed as "single creator, dual owner": if one partner deletes it, it remains shared, just moved to the trash (for both users) until it's deleted from the system (by the normal server task). Only the "creator" user can stop "partner sharing" on the photo, but every other permission is "owned" by both partners… :) Essentially there's only one item, one metadata bundle, one of everything, but the item is "flagged" as being present in two Libraries. I know part of the problem with this is filesystem structure, so forgive me for possibly oversimplifying everything… I sympathize with the difficulty of developing this feature, and am just sharing my thoughts after a Discord interaction about this issue… FWIW, for the more general "media sharing", I think albums are the only (sane) way to go, with permissions being set on the album, not individual media item. Thank you for all your work!

deekerman commented

Author

Owner

@Laptop765 commented on GitHub (Aug 27, 2025):

Just sharing my humble 2¢ on this…

In terms of Partner Sharing (which for me should always be viewed in a significantly different way from just "photo sharing"), I think it should always be viewed as "single creator, dual owner": if one partner deletes it, it remains shared, just moved to the trash (for both users) until it's deleted from the system (by the normal server task). Only the "creator" user can stop "partner sharing" on the photo, but every other permission is "owned" by both partners… :)

Essentially there's only one item, one metadata bundle, one of everything, but the item is "flagged" as being present in two Libraries.

I know part of the problem with this is filesystem structure, so forgive me for possibly oversimplifying everything… I sympathize with the difficulty of developing this feature, and am just sharing my thoughts after a Discord interaction about this issue…

FWIW, for the more general "media sharing", I think albums are the only (sane) way to go, with permissions being set on the album, not individual media item.

Thank you for all your work!

This is exactly what my wife and I were hoping for. We have a test deployment and are wanting things like tags to be shared and the ability to add each others photos to favorites.

@Laptop765 commented on GitHub (Aug 27, 2025): > Just sharing my humble 2¢ on this… > > In terms of Partner Sharing (which for me should always be viewed in a significantly different way from just "photo sharing"), I think it should always be viewed as "single creator, dual owner": if one partner deletes it, it remains shared, just moved to the trash (for both users) until it's deleted from the system (by the normal server task). Only the "creator" user can stop "partner sharing" on the photo, but every other permission is "owned" by both partners… :) > > Essentially there's only one item, one metadata bundle, one of everything, but the item is "flagged" as being present in two Libraries. > > I know part of the problem with this is filesystem structure, so forgive me for possibly oversimplifying everything… I sympathize with the difficulty of developing this feature, and am just sharing my thoughts after a Discord interaction about this issue… > > FWIW, for the more general "media sharing", I think albums are the only (sane) way to go, with permissions being set on the album, not individual media item. > > Thank you for all your work! This is exactly what my wife and I were hoping for. We have a test deployment and are wanting things like tags to be shared and the ability to add each others photos to favorites.

deekerman commented

Author

Owner

@orrinwitt commented on GitHub (Aug 29, 2025):

This is mentioned earlier in this thread, but I would also love to see either

the option to share facial recognition profiles between the administrator and other users, or
the option to run the current user's facial recognition on partner shared assets.

This would result in greatly improved search functionality. I assume most of the use case for Immich servers with multiple users is storing and sharing photos between family members, so this seems like something that a lot of users would benefit from.

I would also love to see the option to

lock assets in a shared album or
partner share a locked folder

so that, for instance, spouses can have shared photos visible to each other, but not appear in their timelines or be visible to others. (this one was dismissed pretty quickly when I suggested it as a feature, but I don't think it was really even seriously considered)

@orrinwitt commented on GitHub (Aug 29, 2025): This is mentioned earlier in this thread, but I would also love to see either - the option to share facial recognition profiles between the administrator and other users, or - the option to run the current user's facial recognition on partner shared assets. This would result in greatly improved search functionality. I assume most of the use case for Immich servers with multiple users is storing and sharing photos between family members, so this seems like something that a lot of users would benefit from. I would also love to see the option to - lock assets in a shared album or - partner share a locked folder so that, for instance, spouses can have shared photos visible to each other, but not appear in their timelines or be visible to others. (this one was dismissed pretty quickly when I suggested it as a feature, but I don't think it was really even seriously considered)

deekerman commented

Author

Owner

@s-martin commented on GitHub (Aug 30, 2025):

The new geolocation utility (#20758) has also the limitation that partner's assets cannot be geolocated.

@s-martin commented on GitHub (Aug 30, 2025): The new geolocation utility (#20758) has also the limitation that partner's assets cannot be geolocated.

deekerman commented

Author

Owner

@darktorana commented on GitHub (Aug 30, 2025):

In case more use case scenarios help the devs:

I share my server with my family (Wife, Parents, Grandparents, Siblings, Children, Siblings kids, you get the point).

I'd like Faces, Names & tags to be shared across the server. So that if I have 'FaceG' named and 'UserD' has no photos of that person (owned by themselves or shared) and they then upload an image including 'FaceG' they will automatically be named as such. While I understand the privacy concern for public Immich servers, for Family & Friends that use my server, I am quite happy for them to know the names of these people.

One 'concern' I have with this, that I haven't seen mentioned, is how to name said person (sorry if I missed it).
My idea would be that the first person to 'name' a face, would by the primary on that faces' data.
Whenever a different user first 'sees' a picture that has that face (they upload it or shared to them), the name used would match what the first user to 'name' the face has it currently set to. BUT the second user is able to rename that face for themselves.

IE:

UserA names FaceC as 'Tiffany'. At this time UserD has no pictures with FaceC accessible to them.
UserD uploads an image containing FaceC, it's automatically named as 'Tiffany' as per UserA's name for the face.
UserD renames the face (FaceG) 'Tiffany' to 'Grandma' (or whatever), henceforth that is the name they use.
UserH then has an image shared to them that includes FaceG from UserD for the first time, they've never seen that face before, it would be named 'Tiffany', not 'Grandma'.
UserA shares a new image that includes 'FaceC' to UserD, which would have 'Grandma' showing up on that image for UserD.

I think it goes without saying, that if any user merges face data for two faces, that should apply for everyone on the server. The point being that everyone can assist with getting accurate data for everyone!

Replicate the same done for faces for tags.

That all aside, this is the last thing stopping me from being able to move to Immich, and granted dev time isn't based on this, I will absolutely be buying a server license once it's implemented. Can't very well ask for things without being willing to put up some $.

Cheers to all the devs.

Edit: Changed 'PersonG' to 'FaceG' to make it (hopefully) easier to read and understand.

@darktorana commented on GitHub (Aug 30, 2025): In case more use case scenarios help the devs: I share my server with my family (Wife, Parents, Grandparents, Siblings, Children, Siblings kids, you get the point). I'd like Faces, Names & tags to be shared across the server. So that if I have 'FaceG' named and 'UserD' has no photos of that person (owned by themselves or shared) and they then upload an image including 'FaceG' they will automatically be named as such. While I understand the privacy concern for public Immich servers, for Family & Friends that use my server, I am quite happy for them to know the names of these people. One 'concern' I have with this, that I haven't seen mentioned, is how to name said person (sorry if I missed it). My idea would be that the first person to 'name' a face, would by the primary on that faces' data. Whenever a different user first 'sees' a picture that has that face (they upload it or shared to them), the name used would match what the first user to 'name' the face has it currently set to. BUT the second user is able to rename that face for themselves. IE: 1. UserA names FaceC as 'Tiffany'. At this time UserD has no pictures with FaceC accessible to them. 2. UserD uploads an image containing FaceC, it's automatically named as 'Tiffany' as per UserA's name for the face. 3. UserD renames the face (FaceG) 'Tiffany' to 'Grandma' (or whatever), henceforth that is the name they use. 4. UserH then has an image shared to them that includes FaceG from UserD for the first time, they've never seen that face before, it would be named 'Tiffany', not 'Grandma'. 5. UserA shares a new image that includes 'FaceC' to UserD, which would have 'Grandma' showing up on that image for UserD. I _think_ it goes without saying, that if any user merges face data for two faces, that should apply for everyone on the server. The point being that everyone can assist with getting accurate data for everyone! Replicate the same done for faces for tags. That all aside, this is the last thing stopping me from being able to move to Immich, and granted dev time isn't based on this, I will absolutely be buying a server license once it's implemented. Can't very well ask for things without being willing to put up some $$$. Cheers to all the devs. Edit: Changed 'PersonG' to 'FaceG' to make it (hopefully) easier to read and understand.

deekerman commented

Author

Owner

@alex-pub commented on GitHub (Aug 30, 2025):

I've been following the discussions around this, I'd argue, crucial sharing feature omission in and out for more than a year and it saddens me that the matter didn't really move much towards a solution. I've been trying to figure out a way to live with this omission for nearly as long and have finally settled on one thing that works for me and my family while waiting for a proper solution: multi-profile setup.

It works like this:

All of us have our own personal profiles and we choose whether we share images/albums as we please without any expectation of them being properly searchable. We also use these profiles for auto-backup and things of that nature.
There is one main family profile that we all use when we want to share images/albums with each other - this one keeps all the facial recognition and location goodies. This profile doesn't have auto-backup, not even for specific local albums, turned on on anyone's device as there seems to be problem indexing the timeline (only the person who auto-uploaded sees them on the timeline) - all uploads here are deliberate (which they should be for shared resources, I'd argue, anyway).

Now, here's the kicker - each of us is running Immich with the 'personal' profile on their Android's personal profile, and then we also run Immich from the Work profiles which connects to the shared family account. That way we can neatly separate personal and family images and treat them accordingly.

If there was a quick way to switch between accounts (a la Slack from several years back when it didn't allow mixing content/spaces) it would make it much, much more user-friendly as we wouldn't have to run two instances, but even like this it's surprisingly functional.

As for how to implement it properly - privacy and sharing are often very tricky topics and I understand devs' reluctance of coming up with a complete solution. That being said, while the issue is debated, if I may suggest a relatively simple temp measure that would already make a world of difference: Allow 're-indexing/reprocessing' of shared/partner albums.

That way, when an image/album is shared with you, it would be pitted against your own 'local' facial data/tags and if it recognizes someone from your own dataset it it will add a local tag for the 'remote' image. This way nobody's privacy is compromised as the images were already deliberately shared with you - you can download and re-upload them for the exact same effect - what will you or will not recognize on those images is your and your problem only. The downside is, obviously, a new facial reprocessing for each share but I'd be more than happy with such 'side-effect'.

Anyway, good work folks - solving this issue would turn it from good to great, essential even!

@alex-pub commented on GitHub (Aug 30, 2025): I've been following the discussions around this, I'd argue, crucial sharing feature omission in and out for more than a year and it saddens me that the matter didn't really move much towards a solution. I've been trying to figure out a way to live with this omission for nearly as long and have finally settled on one thing that works for me and my family while waiting for a proper solution: multi-profile setup. It works like this: - All of us have our own personal profiles and we choose whether we share images/albums as we please without any expectation of them being properly searchable. We also use these profiles for auto-backup and things of that nature. - There is one main family profile that we all use when we want to share images/albums with each other - this one keeps all the facial recognition and location goodies. This profile doesn't have auto-backup, not even for specific local albums, turned on on anyone's device as there seems to be problem indexing the timeline (only the person who auto-uploaded sees them on the timeline) - all uploads here are deliberate (which they should be for shared resources, I'd argue, anyway). Now, here's the kicker - each of us is running Immich with the 'personal' profile on their Android's personal profile, and then we also run Immich from the Work profiles which connects to the shared family account. That way we can neatly separate personal and family images and treat them accordingly. If there was a quick way to switch between accounts (a la Slack from several years back when it didn't allow mixing content/spaces) it would make it much, much more user-friendly as we wouldn't have to run two instances, but even like this it's surprisingly functional. As for how to implement it properly - privacy and sharing are often very tricky topics and I understand devs' reluctance of coming up with a complete solution. That being said, while the issue is debated, if I may suggest a relatively simple temp measure that would already make a world of difference: Allow 're-indexing/reprocessing' of shared/partner albums. That way, when an image/album is shared with you, it would be pitted against your own 'local' facial data/tags and if it recognizes someone from your own dataset it it will add a local tag for the 'remote' image. This way nobody's privacy is compromised as the images were already deliberately shared with you - you can download and re-upload them for the exact same effect - what will you or will not recognize on those images is your and your problem only. The downside is, obviously, a new facial reprocessing for each share but I'd be more than happy with such 'side-effect'. Anyway, good work folks - solving this issue would turn it from good to great, essential even!

deekerman commented

Author

Owner

@crichardson32 commented on GitHub (Sep 10, 2025):

I would like to also add on to the convo. My wife and I share however she takes 90% of the photos but does not organize them. I normally go through and put them in albums. The problem I am running into is I can not add her photos to an album or shared album. The other thing that is making the process hard is since we have partner sharing enabled I cant seem to find a way to tell which photos in the timeline are hers or mine (since I cant add hers) without actually clicking on each picture.

@crichardson32 commented on GitHub (Sep 10, 2025): I would like to also add on to the convo. My wife and I share however she takes 90% of the photos but does not organize them. I normally go through and put them in albums. The problem I am running into is I can not add her photos to an album or shared album. The other thing that is making the process hard is since we have partner sharing enabled I cant seem to find a way to tell which photos in the timeline are hers or mine (since I cant add hers) without actually clicking on each picture.

deekerman commented

Author

Owner

@Facecloth4523 commented on GitHub (Sep 13, 2025):

I really need this if I'm going to use immich as my go to photo management system

@Facecloth4523 commented on GitHub (Sep 13, 2025): I really need this if I'm going to use immich as my go to photo management system

deekerman commented

Author

Owner

@ianwesty commented on GitHub (Sep 20, 2025):

As much as I appreciated all the hard work in developing this project, this is one of a few missing features that is preventing me from purchasing Immich, as I feel I haven't found my "complete" photo storage solution.
Is there a voting system available, where users could have their say towards what features we feel are important and help steer decisions made towards the development pipeline?

@ianwesty commented on GitHub (Sep 20, 2025): As much as I appreciated all the hard work in developing this project, this is one of a few missing features that is preventing me from purchasing Immich, as I feel I haven't found my "complete" photo storage solution. Is there a voting system available, where users could have their say towards what features we feel are important and help steer decisions made towards the development pipeline?

deekerman commented

Author

Owner

@rmburg commented on GitHub (Sep 20, 2025):

You can add a "👍" reaction to the issue to show that this also affects you. Contributors can sort issues by these reactions to see what issue is important to many users. In fact, this issue is already the open issue with by far the most 👍-reactions.
Please prefer adding reactions over submitting "me too"-style comments, as there are many people subscribed to the issue who all get an e-mail for every comment like this.

@rmburg commented on GitHub (Sep 20, 2025): You can add a "👍" reaction to the issue to show that this also affects you. Contributors can [sort issues by these reactions](https://github.com/immich-app/immich/issues?q=is%3Aissue%20state%3Aopen%20sort%3Areactions-%2B1-desc) to see what issue is important to many users. In fact, this issue is already the open issue with by far the most 👍-reactions. Please prefer adding reactions over submitting "me too"-style comments, as there are many people subscribed to the issue who all get an e-mail for every comment like this.

deekerman commented

Author

Owner

@shajra commented on GitHub (Sep 25, 2025):

Some kind words, first

Firstly, as a new user, I wanted to explicitly mention that many of Immich's features seem well thought out and pleasant to use. I appreciate taking the time to get sharing "right" or "right enough" before implementing all the requested features. That approach is what differentiates this project from one like Nextcloud. It's also what leads me to want to stick with Immich, even if it's lacking in certain areas in the near term.

Problems to solve

I hate jumping into requested features without clarity on the problems solved, so let me list those out with as much solution-independence as I can muster:

My family wants low effort to make custom timelines (whether the official timeline, selecting an album, or otherwise)
We want low effort to include photos shared by others in our custom timelines
Face/object recognition alone is insufficient to satisfy "low effort." We are organizing photos for lots of things that current models don't identify well. But it's nice to have the AI assistance.
If we make a custom timeline, we want a convenient way to reference it (currently, all we have are the folders, albums, and tag views as implemented)
We would appreciate some hierarchy of timelines to facilitate implicit merging. The top of this hierarchy would be "all photos."

A proposed solution

TLDR Highlights:

Make at least the album view hierarchical (the folder view already is).
Give users the power of a query language.
Introduce virtual albums as ways to save queries.

Probably the reductionist programmer in me, but I really see all groupings of pictures as timelines, because most photos have a timestamp. For those that don't, we have a reasonable canonical order.

While I can appreciate the differences between albums and tags in terms of ergonomics and intended usage, there are benefits to unifying their functionality in the backend for architectural simplicity. Ideally, some of this simplicity would expose itself as a UX convenience.

Whether albums, folders, or otherwise, we will have a sidebar that gives a list of queries for timelines. Put these in a tree, instead, and merge-sort the results, and we get a nice hierarchical ordering.

The search bar is already exposing a rich query language to users. This could be made more general without exposing users to something that's practically SQL. Include comparators for album names and folders, as well as tags, and we achieve some unification of implementation. The "Albums" view, "Tags" view, and "Folders" view all just map named nodes on a tree to queries. If a user selects a parent node, we merge-sort the results of all the leaf node queries.

Make it possible to make virtual albums, where a query defines the album. Let users put these albums where they like in the hierarchy. It makes sense to me that users can't add photos directly to virtual albums.

As for sharing... avoid surprises with the UX above. All photos have an "owner," and so to me it would be fine to have an "is:mine" selector in the query if people wanted to see only their stuff. For now, that is the static default query for the personal timeline. But... what if that default could be changed? Another family might want to remove the "is:mine" constraint and have a main timeline for their whole family.

I hope this proposal gives food for thought. Hopefully, it's not too radical to be implemented. Perfecting the semantics of timelines, albums, folders, and tags is challenging due to the variety of conflicting usages. My proposal provides a breakout option when the default semantics are insufficient.

If I overlooked something critical in my proposal, please let me know what it might be.

@shajra commented on GitHub (Sep 25, 2025): # Some kind words, first Firstly, as a new user, I wanted to explicitly mention that many of Immich's features seem well thought out and pleasant to use. I appreciate taking the time to get sharing "right" or "right enough" before implementing all the requested features. That approach is what differentiates this project from one like Nextcloud. It's also what leads me to want to stick with Immich, even if it's lacking in certain areas in the near term. # Problems to solve I hate jumping into requested features without clarity on the problems solved, so let me list those out with as much solution-independence as I can muster: - My family wants low effort to make custom timelines (whether the official timeline, selecting an album, or otherwise) - We want low effort to include photos shared by others in our custom timelines - Face/object recognition alone is insufficient to satisfy "low effort." We are organizing photos for lots of things that current models don't identify well. But it's nice to have the AI assistance. - If we make a custom timeline, we want a convenient way to reference it (currently, all we have are the folders, albums, and tag views as implemented) - We would appreciate some hierarchy of timelines to facilitate implicit merging. The top of this hierarchy would be "all photos." # A proposed solution TLDR Highlights: - Make at least the album view hierarchical (the folder view already is). - Give users the power of a query language. - Introduce _virtual albums_ as ways to save queries. Probably the reductionist programmer in me, but I really see all groupings of pictures as timelines, because most photos have a timestamp. For those that don't, we have a reasonable canonical order. While I can appreciate the differences between albums and tags in terms of ergonomics and intended usage, there are benefits to unifying their functionality in the backend for architectural simplicity. Ideally, some of this simplicity would expose itself as a UX convenience. Whether albums, folders, or otherwise, we will have a sidebar that gives a list of queries for timelines. Put these in a tree, instead, and merge-sort the results, and we get a nice hierarchical ordering. The search bar is already exposing a rich query language to users. This could be made more general without exposing users to something that's practically SQL. Include comparators for album names and folders, as well as tags, and we achieve some unification of implementation. The "Albums" view, "Tags" view, and "Folders" view all just map named nodes on a tree to queries. If a user selects a parent node, we merge-sort the results of all the leaf node queries. Make it possible to make _virtual albums_, where a query defines the album. Let users put these albums where they like in the hierarchy. It makes sense to me that users can't add photos directly to virtual albums. As for sharing... avoid surprises with the UX above. All photos have an "owner," and so to me it would be fine to have an "is:mine" selector in the query if people wanted to see only their stuff. For now, that is the static default query for the personal timeline. But... what if that default could be changed? Another family might want to remove the "is:mine" constraint and have a main timeline for their whole family. I hope this proposal gives food for thought. Hopefully, it's not too radical to be implemented. Perfecting the semantics of timelines, albums, folders, and tags is challenging due to the variety of conflicting usages. My proposal provides a breakout option when the default semantics are insufficient. If I overlooked something critical in my proposal, please let me know what it might be.

deekerman commented

Author

Owner

@kanecko commented on GitHub (Oct 3, 2025):

My use-case is that I have multiple sources of photos/videos (from different users and their phones, as well as external libraries) and I have a TV.
We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information.

@kanecko commented on GitHub (Oct 3, 2025): My use-case is that I have multiple sources of photos/videos (from different users and their phones, as well as external libraries) and I have a TV. We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information.

deekerman commented

Author

Owner

@kpoppel commented on GitHub (Oct 5, 2025):

This is a good issue, and thank you for collecting it all into one. Immich is a fabulous piece of software.
I see "partner sharing" as the highest level of sharing - and the sharing account should be able to allow full editing rights to the partner shared with. Meaning the ability to "delete from shared status" (move the asset to a non-shared album), update of metadata (like GPS) and use of facial recognition data etc. Perhaps allowing the partner to set the editing permission could be a post MVP iteration. But basically allow a partner the same access to not locked and not private albums as the user itself.

I seems many have several accounts backing up photos from mobile phones etc. and assembling them in a pool of all images. Partner sharing seems perfect for this for a low/no effort solution.
I am also the one sorting through the mass of images, so having the ability to update metadata and remove images of that forgotten license plate would be great.

Normal 'sharing' should be limited to view only as one would expect.

@kpoppel commented on GitHub (Oct 5, 2025): This is a good issue, and thank you for collecting it all into one. Immich is a fabulous piece of software. I see "[partner sharing](https://docs.immich.app/features/partner-sharing/)" as the highest level of sharing - and the sharing account should be able to allow full editing rights to the partner shared with. Meaning the ability to "delete from shared status" (move the asset to a non-shared album), update of metadata (like GPS) and use of facial recognition data etc. Perhaps allowing the partner to set the editing permission could be a post MVP iteration. But basically allow a partner the same access to not locked and not private albums as the user itself. I seems many have several accounts backing up photos from mobile phones etc. and assembling them in a pool of all images. Partner sharing seems perfect for this for a low/no effort solution. I am also the one sorting through the mass of images, so having the ability to update metadata and remove images of that forgotten license plate would be great. Normal 'sharing' should be limited to view only as one would expect.

deekerman commented

Author

Owner

@ffchung commented on GitHub (Oct 7, 2025):

I suggest to follow structure:

Pool 1 ---- Lib 1
|~ Lib 2
|- Lib....
|- face and smart search....

Pool 2 ---- Lib 3
|~ Lib 4
|- Lib....
|- face and smart search....

And we set user permission for the pool.

And we can view it by switching the pool and modify the pool photo and face data with different user.

@ffchung commented on GitHub (Oct 7, 2025): I suggest to follow structure: Pool 1 ---- Lib 1 |~ Lib 2 |- Lib.... |- face and smart search.... Pool 2 ---- Lib 3 |~ Lib 4 |- Lib.... |- face and smart search.... And we set user permission for the pool. And we can view it by switching the pool and modify the pool photo and face data with different user.

deekerman commented

Author

Owner

@archont00 commented on GitHub (Oct 7, 2025):

We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information.

I worked around the current limitations of sharing by:

creating a new user for read only access;
creating duplicate read-only mount points of other users photos within the Immich docker container:
adding the other users photos path to a new library, which is owned by the new user.

For this new library, Immich does the machine learning, locations as list and on map, face recognition and face identification, and I use the automatic album creator to create albums based on directory as well.

i.e in docker compose:

    volumes:
      - /some/path/userA:/mnt/media/userA
      - /some/path/userB:/mnt/media/userB
      - /some/path/full_archive:/mnt/media/full_archive
      - /some/path/userA:/mnt/media/userA_ro:ro
      - /some/path/userB:/mnt/media/userB_ro:ro
      - /some/path/full_archive:/mnt/media/full_archive_ro:ro

Note that the users A and B do not use the automatic backup function of Immich android client as I use other solution to sync photos between user's phone and my file server.

The mount points with read/write access are added to a different Immich library owned by me to be able to review photos (ie mainly deleting because garbage bin is the best photographer's friend).

If needed, I do further editing/tagging with tools outside of Immich (digiKam, Google Photos on phone), including transfer from user's photo directory to the centralised archive. From the viewpoint of Immich read-only user nothing changes - all photos are displayed.

@archont00 commented on GitHub (Oct 7, 2025): > We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information. I worked around the current limitations of sharing by: - creating a new user for read only access; - creating duplicate read-only mount points of other users photos within the Immich docker container: - adding the other users photos path to a new library, which is owned by the new user. For this new library, Immich does the machine learning, locations as list and on map, face recognition and face identification, and I use the automatic album creator to create albums based on directory as well. i.e in docker compose: ``` volumes: - /some/path/userA:/mnt/media/userA - /some/path/userB:/mnt/media/userB - /some/path/full_archive:/mnt/media/full_archive - /some/path/userA:/mnt/media/userA_ro:ro - /some/path/userB:/mnt/media/userB_ro:ro - /some/path/full_archive:/mnt/media/full_archive_ro:ro ``` Note that the users A and B do not use the automatic backup function of Immich android client as I use other solution to sync photos between user's phone and my file server. The mount points with read/write access are added to a different Immich library owned by me to be able to review photos (ie mainly deleting because garbage bin is the best photographer's friend). If needed, I do further editing/tagging with tools outside of Immich (digiKam, Google Photos on phone), including transfer from user's photo directory to the centralised archive. From the viewpoint of Immich read-only user nothing changes - all photos are displayed.

deekerman commented

Author

Owner

@ffchung commented on GitHub (Oct 7, 2025):

We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information.

I worked around the current limitations of sharing by:

creating a new user for read only access;

creating duplicate read-only mount points of other users photos within the Immich docker container:

adding the other users photos path to a new library, which is owned by the new user.

For this new library, Immich does the machine learning, locations as list and on map, face recognition and face identification, and I use the automatic album creator to create albums based on directory as well.

i.e in docker compose:
    volumes:
      - /some/path/userA:/mnt/media/userA
      - /some/path/userB:/mnt/media/userB
      - /some/path/full_archive:/mnt/media/full_archive
      - /some/path/userA:/mnt/media/userA_ro:ro
      - /some/path/userB:/mnt/media/userB_ro:ro
      - /some/path/full_archive:/mnt/media/full_archive_ro:ro
Note that the users A and B do not use the automatic backup function of Immich android client as I use other solution to sync photos between user's phone and my file server.

The mount points with read/write access are added to a different Immich library owned by me to be able to review photos (ie mainly deleting because garbage bin is the best photographer's friend).

If needed, I do further editing/tagging with tools outside of Immich (digiKam, Google Photos on phone), including transfer from user's photo directory to the centralised archive. From the viewpoint of Immich read-only user nothing changes - all photos are displayed.

As your settings, I will need set face again on same path with different user.

@ffchung commented on GitHub (Oct 7, 2025): > > We would love to be able to give view access to our TV user so that we could all watch our photos/videos together. Not only view, but to also share the same faces/people/geo information. > > I worked around the current limitations of sharing by: > > - creating a new user for read only access; > - creating duplicate read-only mount points of other users photos within the Immich docker container: > - adding the other users photos path to a new library, which is owned by the new user. > > For this new library, Immich does the machine learning, locations as list and on map, face recognition and face identification, and I use the automatic album creator to create albums based on directory as well. > > i.e in docker compose: > ``` > volumes: > - /some/path/userA:/mnt/media/userA > - /some/path/userB:/mnt/media/userB > - /some/path/full_archive:/mnt/media/full_archive > - /some/path/userA:/mnt/media/userA_ro:ro > - /some/path/userB:/mnt/media/userB_ro:ro > - /some/path/full_archive:/mnt/media/full_archive_ro:ro > ``` > > Note that the users A and B do not use the automatic backup function of Immich android client as I use other solution to sync photos between user's phone and my file server. > > The mount points with read/write access are added to a different Immich library owned by me to be able to review photos (ie mainly deleting because garbage bin is the best photographer's friend). > > If needed, I do further editing/tagging with tools outside of Immich (digiKam, Google Photos on phone), including transfer from user's photo directory to the centralised archive. From the viewpoint of Immich read-only user nothing changes - all photos are displayed. As your settings, I will need set face again on same path with different user.

deekerman commented

Author

Owner

@archont00 commented on GitHub (Oct 8, 2025):

Not a big deal for my use case as I have a large part of my photo library tagged in digiKam and Immich can read it and recognise those known faces on new photos pretty well... Not a solution for others, though.

I still use Immich mainly to have online access to my complete library rather than for tagging/editing.

@archont00 commented on GitHub (Oct 8, 2025): Not a big deal for my use case as I have a large part of my photo library tagged in digiKam and Immich can read it and recognise those known faces on new photos pretty well... Not a solution for others, though. I still use Immich mainly to have online access to my complete library rather than for tagging/editing.

deekerman commented

Author

Owner

@SirBoomBoom commented on GitHub (Oct 8, 2025):

First, thanks for all the hard work! Second, big fan of shared facial recognition data idea, though that's mostly been covered in the above comments.

Finally, the ask I haven't seen yet is a way to share photos based on either Face or Location. Someone mentioned query based "virtual" albums and that would honestly work as well.

Problem I am trying to solve is that I tend to be the photographer among both friends and family and then like to share these photos out. Rather than needing to go and update multiple Shared Albums every time I take some photos I'd love to be able to share a link with friends once and anytime I get a photo of them (or their loved ones) it is automatically added to that "album". Same idea for locations, we do a lot of family things at the grandparents' place and would love it if every photo taken near their property just becomes available to them without me having to remember to go and add them to the appropriate shared albums.

@SirBoomBoom commented on GitHub (Oct 8, 2025): First, thanks for all the hard work! Second, big fan of shared facial recognition data idea, though that's mostly been covered in the above comments. Finally, the ask I haven't seen yet is a way to share photos based on either Face or Location. Someone mentioned query based "virtual" albums and that would honestly work as well. Problem I am trying to solve is that I tend to be the photographer among both friends and family and then like to share these photos out. Rather than needing to go and update multiple Shared Albums every time I take some photos I'd love to be able to share a link with friends once and anytime I get a photo of them (or their loved ones) it is automatically added to that "album". Same idea for locations, we do a lot of family things at the grandparents' place and would love it if every photo taken near their property just becomes available to them without me having to remember to go and add them to the appropriate shared albums.

deekerman commented

https://immich.app/roadmap

Author

Owner

@edubxb commented on GitHub (Oct 13, 2025):

FYI: Updated roadmap

@edubxb commented on GitHub (Oct 13, 2025): FYI: Updated roadmap https://immich.app/roadmap <img width="829" height="1115" alt="Image" src="https://github.com/user-attachments/assets/72ba81c0-f30a-478a-a950-825d67c76402" />

deekerman commented

Author

Owner

@ghost commented on GitHub (Oct 14, 2025):

Hi! Just throwing my situation and suggestion to this. In our family each family member has their own account. The problem is that even with show in timeline you are lacking many features that you would get when having own photos such as search and the map. I think there should be like a sharing category where you can see per person the photos and be able to search and also see the map for those photos. Also possibly an option to add those photos to your personal timeline with the addition of search and the map.

@ghost commented on GitHub (Oct 14, 2025): Hi! Just throwing my situation and suggestion to this. In our family each family member has their own account. The problem is that even with show in timeline you are lacking many features that you would get when having own photos such as search and the map. I think there should be like a sharing category where you can see per person the photos and be able to search and also see the map for those photos. Also possibly an option to add those photos to your personal timeline with the addition of search and the map.

deekerman commented

Author

Owner

@Appelsiini1 commented on GitHub (Oct 14, 2025):

I would like to add to the 'better sharing' umbrella the feature to edit tags in the pictures in a shared album. Right now there is the option to share as an editor but that still doesnt add the capability to edit the tags. I would love if another person that you've explicitly given the editor rights could actually edit the features of the image. Or have I just missed something in the config or something?

@Appelsiini1 commented on GitHub (Oct 14, 2025): I would like to add to the 'better sharing' umbrella the feature to edit tags in the pictures in a shared album. Right now there is the option to share as an editor but that still doesnt add the capability to edit the tags. I would love if another person that you've explicitly given the editor rights could actually edit the features of the image. Or have I just missed something in the config or something?

deekerman commented

Author

Owner

@WorkDal commented on GitHub (Oct 14, 2025):

So much is missing in this app when it comes to sharing and albums.

Multiple owners (maintainers)
ALL users must have the same rights and see the same things as the owners if the rights are given
ALL users must be able to upload pictures to ANY album, if the rights are given
Nested albums
User groups
The ability to share and set permissions on whole groups of albums, or share one album to a user group.

A few practical examples:

We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me.

An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album?

@WorkDal commented on GitHub (Oct 14, 2025): So much is missing in this app when it comes to sharing and albums. - Multiple owners (maintainers) - ALL users must have the same rights and see the same things as the owners if the rights are given - ALL users must be able to upload pictures to ANY album, if the rights are given - Nested albums - User groups - The ability to share and set permissions on whole groups of albums, or share one album to a user group. A few practical examples: We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me. An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album?

deekerman commented

Author

Owner

@SirBoomBoom commented on GitHub (Oct 15, 2025):

A few practical examples:

We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me.

An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album?

Not that it will resolve all your problems, but I did actually recently do something similar to what you are describing. When you go through the Album sharing wizard there is (at least on the PC version) an optional checkbox to allow people to upload photos.

Tried this out at an extended family gathering for the first time a couple of weeks ago and it was nice because I was able to just share a link (using the option to give it a human friendly name on creation) and everyone there was able to view and add photos just fine without any of them even needing an Immich account. Only warning is that I don't remember if it was a setting I chose, but as the owner I was the only one who could delete photos, so if anyone uploaded something on accident I'd have to be the one to remove it. Being able to add additional maintainers would be awesome, but for something quick and easy in a group setting this worked surprisingly well for us.

@SirBoomBoom commented on GitHub (Oct 15, 2025): > A few practical examples: > > We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me. > > An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album? Not that it will resolve all your problems, but I did actually recently do something similar to what you are describing. When you go through the Album sharing wizard there is (at least on the PC version) an optional checkbox to allow people to upload photos. Tried this out at an extended family gathering for the first time a couple of weeks ago and it was nice because I was able to just share a link (using the option to give it a human friendly name on creation) and everyone there was able to view and add photos just fine without any of them even needing an Immich account. Only warning is that I don't remember if it was a setting I chose, but as the owner I was the only one who could delete photos, so if anyone uploaded something on accident I'd have to be the one to remove it. Being able to add additional maintainers would be awesome, but for something quick and easy in a group setting this worked surprisingly well for us.

deekerman commented

Author

Owner

@Frankstar commented on GitHub (Oct 16, 2025):

thumbs up for the missing feature "Face Recognition for shared Albums" or "shared Face/Persons-Data with shared albums"

@Frankstar commented on GitHub (Oct 16, 2025): thumbs up for the missing feature "Face Recognition for shared Albums" or "shared Face/Persons-Data with shared albums"

deekerman commented

Author

Owner

@malheleco commented on GitHub (Oct 16, 2025):

So much is missing in this app when it comes to sharing and albums.
* Multiple owners (maintainers)

When creating an album (or also with existing ones, you can choose whether to add another user as Editor or viewer.

...
A few practical examples:

We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me.

As stated above, there is a way, but my understanding is you are missing the feature that this would automatically apply to new albums if the creator had set up (the currently missing feature) of sharing all albums with another user?

An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album?

That already works, you can create a link for an album and "allow public user to download", "allow public user to upload" or both. It's how I collected photos for various events like this already. The owner of all those photos will be the creator of the album.

@malheleco commented on GitHub (Oct 16, 2025): > So much is missing in this app when it comes to sharing and albums. > > * Multiple owners (maintainers) When creating an album (or also with existing ones, you can choose whether to add another user as Editor or viewer. > ... > A few practical examples: > > We are a family of 4 on vacation. I create an album with the pictures I've taken. But the 3 other members have taken pictures as well. As of now there is no way that they can upload their pictures to the album and maintain it together with me. As stated above, there is a way, but my understanding is you are missing the feature that this would automatically apply to new albums if the creator had set up (the currently missing feature) of sharing all albums with another user? > An event, like a wedding. Wouldn't it be nice if all the guests could upload / share their photos in the same album? That already works, you can create a link for an album and "allow public user to download", "allow public user to upload" or both. It's how I collected photos for various events like this already. The owner of all those photos will be the creator of the album.

deekerman commented

Author

Owner

@TieHaxJan commented on GitHub (Oct 21, 2025):

Tried this out at an extended family gathering for the first time a couple of weeks ago and it was nice because I was able to just share a link (using the option to give it a human friendly name on creation) and everyone there was able to view and add photos just fine without any of them even needing an Immich account. Only warning is that I don't remember if it was a setting I chose, but as the owner I was the only one who could delete photos, so if anyone uploaded something on accident I'd have to be the one to remove it. Being able to add additional maintainers would be awesome, but for something quick and easy in a group setting this worked surprisingly well for us.

I am a photographer and use immich to store and share my images to my clients and it works like a charm, I am the only user and all links i send out are public external links without an account necessary. I would like to have the option to just allow deleting images from an album i shared by anyone, or tag these as this would make it easier for clients to give feedback on what images need re-editing, or should not be published etc.

@TieHaxJan commented on GitHub (Oct 21, 2025): > Tried this out at an extended family gathering for the first time a couple of weeks ago and it was nice because I was able to just share a link (using the option to give it a human friendly name on creation) and everyone there was able to view and add photos just fine without any of them even needing an Immich account. Only warning is that I don't remember if it was a setting I chose, but as the owner I was the only one who could delete photos, so if anyone uploaded something on accident I'd have to be the one to remove it. Being able to add additional maintainers would be awesome, but for something quick and easy in a group setting this worked surprisingly well for us. I am a photographer and use immich to store and share my images to my clients and it works like a charm, I am the only user and all links i send out are public external links without an account necessary. I would like to have the option to just allow deleting images from an album i shared by anyone, or tag these as this would make it easier for clients to give feedback on what images need re-editing, or should not be published etc.

deekerman commented

Author

Owner

@JustCrazyer commented on GitHub (Oct 27, 2025):

I am very much looking forward to sharing Asset data (tags, people, etc.) with home users.

@JustCrazyer commented on GitHub (Oct 27, 2025): I am very much looking forward to sharing Asset data (tags, people, etc.) with home users.

deekerman commented

Author

Owner

@slavanap commented on GitHub (Oct 29, 2025):

I would also add few cents on deduplication across accounts as an admin. It has intersection in sharing if dupes uploaded by different account

@slavanap commented on GitHub (Oct 29, 2025): I would also add few cents on deduplication across accounts as an admin. It has intersection in sharing if dupes uploaded by different account

deekerman commented

Author

Owner

@xuefer commented on GitHub (Oct 30, 2025):

I would also add few cents on deduplication across accounts as an admin. It has intersection in sharing if dupes uploaded by different account

i wouldn't say this feature as useless, me too thought of the same feature. but in my use case other partners are family members that don't play phone/app well, i wouldn't want them to handle this type of management, however i as admin don't want to do this micro-management either like daily or monthly interval. things become more complex than i thought initially

@xuefer commented on GitHub (Oct 30, 2025): > I would also add few cents on deduplication across accounts as an admin. It has intersection in sharing if dupes uploaded by different account i wouldn't say this feature as useless, me too thought of the same feature. but in my use case other partners are family members that don't play phone/app well, i wouldn't want them to handle this type of management, however i as admin don't want to do this micro-management either like daily or monthly interval. things become more complex than i thought initially

deekerman commented

Author

Owner

@TrueDevanon commented on GitHub (Oct 30, 2025):

Immich Linked Assets aka partner sharing with metadata/tags/people (without duplicates on the hard drive)

I create some kind of complex solution while we are waiting for a built-in one.
It's not ideal, but it works and is easy to install and remove.
I use it personally for sharing photos with my family.
If you can test it and report bugs, I would appreciate it.
Current state: works on my machine
Here is the project: https://github.com/TrueDevanon/immich-linked-assets

@TrueDevanon commented on GitHub (Oct 30, 2025): **Immich Linked Assets aka partner sharing with metadata/tags/people (without duplicates on the hard drive)** I create some kind of complex solution while we are waiting for a built-in one. It's not ideal, but it works and is easy to install and remove. I use it personally for sharing photos with my family. If you can test it and report bugs, I would appreciate it. Current state: works on my machine Here is the project: https://github.com/TrueDevanon/immich-linked-assets

deekerman commented

Author

Owner

@juliienp commented on GitHub (Nov 25, 2025):

It would be very useful to allow adding a photo owned by another user from one shared album into another shared album.
Use case:

I share an album with my wife for our daughter’s photos.
I also created a second shared album called “Print Selection”.
I cannot add a photo she owns from the first shared album into the second.

This limitation comes up frequently in help-desk-support discussions on Discord.

PUT /api/albums/xxxx-xxxx-xxxx-xxxx-xxxxxxxx/assets
{"ids":["yyyy-yyyyy-yyyy-yyyy-yyyyyyy"]}

Response :
[
    {
        "id": "yyyy-yyyyy-yyyy-yyyy-yyyyyyy",
        "success": false,
        "error": "no_permission"
    }
]

@juliienp commented on GitHub (Nov 25, 2025): It would be very useful to allow adding a photo owned by another user from one shared album into another shared album. Use case: 1. I share an album with my wife for our daughter’s photos. 2. I also created a second shared album called “Print Selection”. 3. I cannot add a photo she owns from the first shared album into the second. This limitation comes up frequently in help-desk-support discussions on Discord. ``` PUT /api/albums/xxxx-xxxx-xxxx-xxxx-xxxxxxxx/assets {"ids":["yyyy-yyyyy-yyyy-yyyy-yyyyyyy"]} Response : [ { "id": "yyyy-yyyyy-yyyy-yyyy-yyyyyyy", "success": false, "error": "no_permission" } ] ```

deekerman commented

Author

Owner

@higheraims commented on GitHub (Nov 29, 2025):

I'm here following the link from duplicate #24176 because this is exactly what I need.

I have a huge existing library that I have already working with Resilio Sync on multiple machines and I'd like Immich on my TrueNAS box to be able to display this external library for multiple users.

@higheraims commented on GitHub (Nov 29, 2025): I'm here following the link from duplicate #24176 because this is exactly what I need. I have a huge existing library that I have already working with Resilio Sync on multiple machines and I'd like Immich on my TrueNAS box to be able to display this external library for multiple users.

deekerman commented

Author

Owner

@rwjorgen64 commented on GitHub (Nov 30, 2025):

Think of if this way. For any photo shared, all the information pertaining to the photo should also be shared: what, where, who, when, discussion topics. If a photo appears in a shared library, "who" is tagged should also be available with the sharing, as well as 'when', any tags, etc. In this manner, my shared users can search photos by person, place, date, or other tag.

I'm creating a library of historical family photos. I use the Albums to help me sort which photos would be of interest to different family members. My cousins on one side of the family care about media that pertains to them, and the cousins on the other side of the family care about media that pertains to them, and our family appears in both albums.

Example: my dad took a bunch of 8mm movies from 1947-1983, which I'm attempting to make available to relatives who have never seen those movies - and who have no idea that they appear in the movie! Many movies are from family reunions from years gone by, so I want the next generation to discover who all in in those movies (e.g. parents, siblings, cousins, aunts & uncles, grandparents).

@rwjorgen64 commented on GitHub (Nov 30, 2025): Think of if this way. For any photo shared, all the information pertaining to the photo should also be shared: what, where, who, when, discussion topics. If a photo appears in a shared library, "who" is tagged should also be available with the sharing, as well as 'when', any tags, etc. In this manner, my shared users can search photos by person, place, date, or other tag. I'm creating a library of historical family photos. I use the Albums to help me sort which photos would be of interest to different family members. My cousins on one side of the family care about media that pertains to them, and the cousins on the other side of the family care about media that pertains to them, and our family appears in both albums. Example: my dad took a bunch of 8mm movies from 1947-1983, which I'm attempting to make available to relatives who have never seen those movies - and who have no idea that they appear in the movie! Many movies are from family reunions from years gone by, so I want the next generation to discover who all in in those movies (e.g. parents, siblings, cousins, aunts & uncles, grandparents).

deekerman commented

Author

Owner

@juliienp commented on GitHub (Dec 1, 2025):

I made a fork and added a commit that disables this check. It’s a very rough workaround, intended only for my own local build of the immich-server Docker image.
The proper fix should be to verify whether the user actually has permission for both the asset and the shared album.

@juliienp commented on GitHub (Dec 1, 2025): I made a fork and added a commit that disables this check. It’s a very rough workaround, intended only for my own local build of the immich-server Docker image. The proper fix should be to verify whether the user actually has permission for both the asset and the shared album.

deekerman commented

Author

Owner

@txemi commented on GitHub (Dec 1, 2025):

Hi team,

Reaching out following the closure of my proposal in discussion #24290.

I fully understand the rationale behind the closure due to the current feature freeze and the broader re-architecture planned for the sharing module.

I just wanted to drop a quick note to ensure the specific concept of "local-only" execution (allowing face recognition on shared content without sharing the actual ML data/privacy tokens) is on the radar. It might be a valuable architectural pattern to consider when designing the new sharing system to handle privacy constraints.

I’ve subscribed to this thread to follow the progress, and I would be more than happy to help test the new implementation as soon as it is ready for a spin.

Thanks for the great work!

@txemi commented on GitHub (Dec 1, 2025): Hi team, Reaching out following the closure of my proposal in discussion #24290. I fully understand the rationale behind the closure due to the current feature freeze and the broader re-architecture planned for the sharing module. I just wanted to drop a quick note to ensure the specific concept of **"local-only" execution** (allowing face recognition on shared content without sharing the actual ML data/privacy tokens) is on the radar. It might be a valuable architectural pattern to consider when designing the new sharing system to handle privacy constraints. I’ve subscribed to this thread to follow the progress, and I would be more than happy to help test the new implementation as soon as it is ready for a spin. Thanks for the great work!

deekerman commented

Author

Owner

@hexxone commented on GitHub (Dec 6, 2025):

Hey there! First of all, thank you, Immich team, for your continued efforts in planning ahead and making this amazing app future-proof!
I would also like to offer my thoughts here.

The option to add 'Shared Albums' to timelines would be highly appreciated. Essentially, this would work like this: https://github.com/immich-app/immich/pull/23660
For me, showing all my partner's pictures in the timeline is a bit too much. It would be much nicer to narrow this down to some shared albums.
A "de-duplication" feature for "partner sharing" like it's done for "photos", where it detects and suggests merging/linking people with the same faces. I assume there is already a "hash" of some sort for processed faces?

Thanks in advance, keep it up 🥇

@hexxone commented on GitHub (Dec 6, 2025): Hey there! First of all, thank you, Immich team, for your continued efforts in planning ahead and making this amazing app future-proof! I would also like to offer my thoughts here. 1. The option to add 'Shared Albums' to timelines would be highly appreciated. Essentially, this would work like this: https://github.com/immich-app/immich/pull/23660 For me, showing all my partner's pictures in the timeline is a bit too much. It would be much nicer to narrow this down to some shared albums. 2. A "de-duplication" feature for "partner sharing" like it's done for "photos", where it detects and suggests merging/linking people with the same faces. I assume there is already a "hash" of some sort for processed faces? Thanks in advance, keep it up 🥇

deekerman commented

Author

Owner

@Oniric75 commented on GitHub (Dec 8, 2025):

i came here after a failed search and posting a feature request for sharing face recognition : #24464
the ability to share face recognition would be greatly appreciated for family usage !

thanks again for all the great work ! 👍

@Oniric75 commented on GitHub (Dec 8, 2025): i came here after a failed search and posting a feature request for sharing face recognition : #24464 the ability to share face recognition would be greatly appreciated for family usage ! thanks again for all the great work ! 👍

deekerman commented

Author

Owner

@SushiByte-beep commented on GitHub (Dec 14, 2025):

As a workaround we used to share a single admin user, but having that one logged in and used on multiple devices caused connections problems.

Currently our setup looks like this:

Each partner uploads pictures from their own phone to their own user
All other pictures (non smartphone camera/send by others) get put on a shared network-folder following our own folder standard and get uploaded into immich as external libraries on the admin account.

As you can imagine this makes building an album together a huge pain. We would love to be able to see partners favorites and be able to make albums from that picture... After all once a library is shared they could technically download and re-upload a copy owned by themselves so i don't know what the security here is securing.

The one ownership thing that makes sense is limiting who can delete a pictures and maybe hidden favorites.

@SushiByte-beep commented on GitHub (Dec 14, 2025): As a workaround we used to share a single admin user, but having that one logged in and used on multiple devices caused connections problems. Currently our setup looks like this: - Each partner uploads pictures from their own phone to their own user - All other pictures (non smartphone camera/send by others) get put on a shared network-folder following our own folder standard and get uploaded into immich as external libraries on the admin account. As you can imagine this makes building an album together a huge pain. We would love to be able to see partners favorites and be able to make albums from that picture... After all once a library is shared they could technically download and re-upload a copy owned by themselves so i don't know what the security here is securing. The one ownership thing that makes sense is limiting who can delete a pictures and maybe hidden favorites.

deekerman commented

Author

Owner

@separac commented on GitHub (Dec 14, 2025):

I came here for the same.. man this is really necessary to even further convince my wife to adopt immich 👍

@separac commented on GitHub (Dec 14, 2025): I came here for the same.. man this is really necessary to even further convince my wife to adopt immich 👍

deekerman commented

Author

Owner

@dk761 commented on GitHub (Dec 15, 2025):

Throw in my 2 cents to support this feature.

Face recognition (People) should be shareable (read-only at the beginning) with shared libraries / partners

Problem

When photos are shared (partners or albums), the recipient:

Can see the photos
Can see the faces in those photos
Cannot see People / face groupings

Each user must re-run face recognition and re-label the same faces, which makes the People feature impractical for family or partner setups.

Why this is an issue

Face detection is derived image metadata, not user content
Other derived metadata (EXIF, location, timestamps) is already shared
Privacy arguments don’t apply once the photo itself is explicitly shared
This is unnecessary duplication of ML work and a poor UX.

Face recognition should be treated as image-derived metadata.
At minimum, read-only sharing of face clusters would immediately fix People for shared libraries without introducing privacy or complexity concerns.

@dk761 commented on GitHub (Dec 15, 2025): Throw in my 2 cents to support this feature. ---------- ### Face recognition (People) should be shareable (read-only at the beginning) with shared libraries / partners **Problem** When photos are shared (partners or albums), the recipient: 1. Can see the photos 2. Can see the faces in those photos 3. Cannot see People / face groupings Each user must re-run face recognition and re-label the same faces, which makes the People feature impractical for family or partner setups. **Why this is an issue** 1. Face detection is derived image metadata, not user content 2. Other derived metadata (EXIF, location, timestamps) is already shared 3. Privacy arguments don’t apply once the photo itself is explicitly shared 4. This is unnecessary duplication of ML work and a poor UX. Face recognition should be treated as image-derived metadata. At minimum, read-only sharing of face clusters would immediately fix People for shared libraries without introducing privacy or complexity concerns.

deekerman commented

Author

Owner

@sezercoban commented on GitHub (Dec 17, 2025):

Straggling with making a shared photo album for family. Created users and uploaded all data from my own account. made them partners and also shared albums with others. But they cant see faces in photos, cant use map for location.
This idea is very good, will level up immich.

@sezercoban commented on GitHub (Dec 17, 2025): Straggling with making a shared photo album for family. Created users and uploaded all data from my own account. made them partners and also shared albums with others. But they cant see faces in photos, cant use map for location. This idea is very good, will level up immich.

deekerman commented

Author

Owner

@angryviking commented on GitHub (Dec 22, 2025):

As others have mentioned, the Partner Sharing in Immich doesn't work well for families and the planned improvements I have seen (sharing of facial recognition tags, etc) don't sound like it will improve things any.
While there are many reasons that Immich is better than Synology Photos, one thing that Synology Photos does well is sharing.
They use a concept of a Shared Space vs. Private Space. Each user gets their own Private Space that the user manages, but the user can choose to upload photos to a Shared Space (or move photos to / from their Private Space to the Shared Space). This Shared Space can be managed by any user with the correct permissions. That means no duplication of face tags if one user uses one name, but their partner uses another, for example. Any user with permissions can correct tags or date / time or GPS issues, etc.
On the back-end each user's photos are still stored separately in their own directory based on user name to help organize the file system.
I would love to see this or a similar concept be adopted by Immich.

@angryviking commented on GitHub (Dec 22, 2025): As others have mentioned, the Partner Sharing in Immich doesn't work well for families and the planned improvements I have seen (sharing of facial recognition tags, etc) don't sound like it will improve things any. While there are many reasons that Immich is better than Synology Photos, one thing that Synology Photos does well is sharing. They use a concept of a Shared Space vs. Private Space. Each user gets their own Private Space that the user manages, but the user can choose to upload photos to a Shared Space (or move photos to / from their Private Space to the Shared Space). This Shared Space can be managed by any user with the correct permissions. That means no duplication of face tags if one user uses one name, but their partner uses another, for example. Any user with permissions can correct tags or date / time or GPS issues, etc. On the back-end each user's photos are still stored separately in their own directory based on user name to help organize the file system. I would love to see this or a similar concept be adopted by Immich.

deekerman commented

Author

Owner

@barncrow commented on GitHub (Dec 23, 2025):

This issue is the reason I'm not using Immich. I'm hosting a family photo album that will be viewed by dozens of people, all logging in with a single "guest user" type account. I started with Immich, but then realized none of my relatives would be able to see all face-recognition data I worked so hard on. I'm using PiGallery2 instead; it's got quirks, but it works great as a photo gallery (I do all my DAM in Digikam).

@barncrow commented on GitHub (Dec 23, 2025): This issue is the reason I'm not using Immich. I'm hosting a family photo album that will be viewed by dozens of people, all logging in with a single "guest user" type account. I started with Immich, but then realized none of my relatives would be able to see all face-recognition data I worked so hard on. I'm using PiGallery2 instead; it's got quirks, but it works great as a photo gallery (I do all my DAM in Digikam).

deekerman commented

Author

Owner

@tristanjodsalz commented on GitHub (Dec 23, 2025):

Are there concrete ideas on how this type of sharing will be implemented?

I personally think the concept of a shared space is a bad idea. I want my photos to be available in one place. It defeats the purpose if I have to search my own and a shared space.

My proposed solution would be to show photos from shared albums in your timeline and other views like the map.

For faces, there are two options.
The first is to just share everything.
The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked.

I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users.

I hope that you/we will come to a good solution (I am open for discussion).

Tristan :D

@tristanjodsalz commented on GitHub (Dec 23, 2025): Are there concrete ideas on how this type of sharing will be implemented? I personally think the concept of a shared space is a bad idea. I want my photos to be available in _one_ place. It defeats the purpose if I have to search my own and a shared space. My proposed solution would be to show photos from shared albums in your timeline and other views like the map. For faces, there are two options. The first is to just share everything. The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked. I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users. I hope that you/we will come to a good solution (I am open for discussion). Tristan :D

deekerman commented

2026-02-20 02:16:50 -05:00

Author

Owner

@barncrow commented on GitHub (Dec 24, 2025):

Hmmm...yes, it's a tangle. And my own use-case may fall outside of Immich's intended domain. I'm building a family photo album, to be maintained by myself (as long as I'm still alive), and viewed by people from all over...some of whom I might never meet. Those people should not be able to edit anything (though leaving comments might be nice), but they should be able to view the time, location, captions, and name/face data that I've written into the metadata of each photo (using Digikam).

@barncrow commented on GitHub (Dec 24, 2025): Hmmm...yes, it's a tangle. And my own use-case may fall outside of Immich's intended domain. I'm building a family photo album, to be maintained by myself (as long as I'm still alive), and viewed by people from all over...some of whom I might never meet. Those people should not be able to edit anything (though leaving comments might be nice), but they should be able to view the time, location, captions, and name/face data that I've written into the metadata of each photo (using Digikam).

deekerman commented

Author

Owner

@cookiemoritz commented on GitHub (Dec 27, 2025):

An Editor of a shared album shoulb be allowed to remove pictures from the album, or rename it and the description. This is only possible for the owner, and makes it very difficult to work on joint albums.

I understand that there is the editor, but it would be nice to have a additional role, like an co owner. who has similar rights to the owner.

I would suggest having a custome role, where you can assign permissions such as deleting or renaming for certain persons, to allow them to have very similar permissions as the owner.

This would be very nice to have a shared album with family members. or is there a better way of doing this?

@cookiemoritz commented on GitHub (Dec 27, 2025): An Editor of a shared album shoulb be allowed to remove pictures from the album, or rename it and the description. This is only possible for the owner, and makes it very difficult to work on joint albums. I understand that there is the editor, but it would be nice to have a additional role, like an co owner. who has similar rights to the owner. I would suggest having a custome role, where you can assign permissions such as deleting or renaming for certain persons, to allow them to have very similar permissions as the owner. This would be very nice to have a shared album with family members. or is there a better way of doing this?

deekerman commented

2026-02-20 02:16:50 -05:00

Author

Owner

@photoserver-pro commented on GitHub (Dec 28, 2025):

I would like to strongly support this proposal.

I am currently in the process of building a photo server for family and friends. I really love Immich — it is fast, modern, and clearly scalable (I am coming from Piwigo). Thank you very much to the team for all the work you are putting into this project.

To my surprise, I noticed that there is currently no permission management at the level of photo sources / libraries.

In my setup, I use External Libraries to ingest multiple, separate photo collections into a central Immich instance, where everything is managed centrally. As an administrator, I would like to grant users access to all or selected external libraries, depending on their role and relationship. The key requirement is to be able to assign user permissions per external library.

At the same time, all server-side functionality — tag management, face recognition, metadata handling, and other processing — should remain centrally controlled by me as admin.

In the long run, this installation will grow to 750,000+ images, so proper permission management is not a “nice to have” but a fundamental requirement for multi-user setups.

I am therefore a strong supporter of introducing library-level permission management and am very happy to see this topic on the roadmap. Thanks in advance 🥇💪🏻

@photoserver-pro commented on GitHub (Dec 28, 2025): I would like to strongly support this proposal. I am currently in the process of building a photo server for family and friends. I really love Immich — it is fast, modern, and clearly scalable (I am coming from Piwigo). Thank you very much to the team for all the work you are putting into this project. To my surprise, I noticed that there is currently no permission management at the level of photo sources / libraries. In my setup, I use External Libraries to ingest multiple, separate photo collections into a central Immich instance, where everything is managed centrally. As an administrator, I would like to grant users access to all or selected external libraries, depending on their role and relationship. The key requirement is to be able to assign user permissions per external library. At the same time, all server-side functionality — tag management, face recognition, metadata handling, and other processing — should remain centrally controlled by me as admin. In the long run, this installation will grow to 750,000+ images, so proper permission management is not a “nice to have” but a fundamental requirement for multi-user setups. I am therefore a strong supporter of introducing library-level permission management and am very happy to see this topic on the roadmap. Thanks in advance 🥇💪🏻 <img width="2060" height="1054" alt="Image" src="https://github.com/user-attachments/assets/0381feaa-5b4e-4971-b63f-89d293add475" />

deekerman commented

Author

Owner

@wjarka commented on GitHub (Dec 30, 2025):

Are there concrete ideas on how this type of sharing will be implemented?

I personally think the concept of a shared space is a bad idea. I want my photos to be available in one place. It defeats the purpose if I have to search my own and a shared space.

My proposed solution would be to show photos from shared albums in your timeline and other views like the map.

For faces, there are two options. The first is to just share everything. The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked.

I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users.

I hope that you/we will come to a good solution (I am open for discussion).

Tristan :D

I was thinking even - each user has their separate model for face recognition and each tags their own photos. What could help a lot would be just to say "X" in my library is "Y" in the other library. And while the system wouldn't benefit from a shared training data - it would at least let both users find the person in both libraries.

@wjarka commented on GitHub (Dec 30, 2025): > Are there concrete ideas on how this type of sharing will be implemented? > > I personally think the concept of a shared space is a bad idea. I want my photos to be available in _one_ place. It defeats the purpose if I have to search my own and a shared space. > > My proposed solution would be to show photos from shared albums in your timeline and other views like the map. > > For faces, there are two options. The first is to just share everything. The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked. > > I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users. > > I hope that you/we will come to a good solution (I am open for discussion). > > Tristan :D I was thinking even - each user has their separate model for face recognition and each tags their own photos. What could help a lot would be just to say "X" in my library is "Y" in the other library. And while the system wouldn't benefit from a shared training data - it would at least let both users find the person in both libraries.

deekerman commented

Author

Owner

@photoserver-pro commented on GitHub (Dec 30, 2025):

I would like to add another real-world use case to this discussion that highlights why a well-designed sharing and permission model is essential.

We are planning to use Immich as a central family photo server, consolidating the large and historically grown photo archives of multiple family members. Each archive is ingested via separate External Libraries into a single, central Immich instance. In total, this system will grow beyond 750,000 photos.

This setup leads to two key requirements:

Per-user scoped views of the archive
Each family member should, by default, only see their own photos when logging in.
This is not primarily a privacy concern, but a usability one: with hundreds of thousands of images, the only way to navigate efficiently is to start from a personally relevant subset of the archive.
A global, shared view for discovery
At the same time, it must be possible (e.g. via a central “family” account) to browse all photos across all libraries, in order to rediscover old images, explore shared history, and curate content together.

To make this work, one aspect is absolutely critical:

There must be a single, shared database for people / face recognition (as in Qnap Qumagie)

All family members — regardless of whether they are using their personal account or a master/family account — need to work on the same set of recognized persons. In a family context, there is naturally a large overlap of faces across all libraries. Splitting person management per user would break this model entirely.

The end goal is to be able to search across the entire archive for people like “uncle X”, “aunt Y”, “grandmother Z”, and reliably find all photos, regardless of which family member originally owned or imported them.

In summary:
Per-user visibility and shared semantic data (especially people) must coexist. This combination is what enables Immich to scale from a personal photo app to a true multi-user, family-scale photo archive.

Thanks for considering this perspective — it reflects how Immich is already being evaluated for long-term, large-scale real-world usage.

@photoserver-pro commented on GitHub (Dec 30, 2025): I would like to add another real-world use case to this discussion that highlights why a well-designed sharing and permission model is essential. We are planning to use Immich as a central family photo server, consolidating the large and historically grown photo archives of multiple family members. Each archive is ingested via separate External Libraries into a single, central Immich instance. In total, this system will grow beyond 750,000 photos. This setup leads to two key requirements: 1. Per-user scoped views of the archive Each family member should, by default, only see their own photos when logging in. This is not primarily a privacy concern, but a usability one: with hundreds of thousands of images, the only way to navigate efficiently is to start from a personally relevant subset of the archive. 2. A global, shared view for discovery At the same time, it must be possible (e.g. via a central “family” account) to browse all photos across all libraries, in order to rediscover old images, explore shared history, and curate content together. To make this work, one aspect is absolutely critical: There must be a single, shared database for people / face recognition (as in Qnap Qumagie) All family members — regardless of whether they are using their personal account or a master/family account — need to work on the same set of recognized persons. In a family context, there is naturally a large overlap of faces across all libraries. Splitting person management per user would break this model entirely. The end goal is to be able to search across the entire archive for people like “uncle X”, “aunt Y”, “grandmother Z”, and reliably find all photos, regardless of which family member originally owned or imported them. In summary: Per-user visibility and shared semantic data (especially people) must coexist. This combination is what enables Immich to scale from a personal photo app to a true multi-user, family-scale photo archive. Thanks for considering this perspective — it reflects how Immich is already being evaluated for long-term, large-scale real-world usage.

deekerman commented

Author

Owner

@xuefer commented on GitHub (Dec 30, 2025):

Are there concrete ideas on how this type of sharing will be implemented?
I personally think the concept of a shared space is a bad idea. I want my photos to be available in one place. It defeats the purpose if I have to search my own and a shared space.
My proposed solution would be to show photos from shared albums in your timeline and other views like the map.
For faces, there are two options. The first is to just share everything. The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked.
I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users.
I hope that you/we will come to a good solution (I am open for discussion).
Tristan :D

I was thinking even - each user has their separate model for face recognition and each tags their own photos. What could help a lot would be just to say "X" in my library is "Y" in the other library. And while the system wouldn't benefit from a shared training data - it would at least let both users find the person in both libraries.

i'd say recognition isn't a problem in real world, sane people do sane recognition (matching), the problem is the naming nicks maybe different. your aunt might be my sister, your sweet heart might be my naughty angel

@xuefer commented on GitHub (Dec 30, 2025): > > Are there concrete ideas on how this type of sharing will be implemented? > > I personally think the concept of a shared space is a bad idea. I want my photos to be available in _one_ place. It defeats the purpose if I have to search my own and a shared space. > > My proposed solution would be to show photos from shared albums in your timeline and other views like the map. > > For faces, there are two options. The first is to just share everything. The other would be to just share which faces belong to the same person. Then each user could still edit (Name and image) their faces individually but the graph of face data would be linked. > > I don’t completely understand the face recognition system of Immich but this should be possible if the raw face embedding data is shared with other users. > > I hope that you/we will come to a good solution (I am open for discussion). > > Tristan :D > > I was thinking even - each user has their separate model for face recognition and each tags their own photos. What could help a lot would be just to say "X" in my library is "Y" in the other library. And while the system wouldn't benefit from a shared training data - it would at least let both users find the person in both libraries. i'd say recognition isn't a problem in real world, sane people do sane recognition (matching), the problem is the naming nicks maybe different. your aunt might be my sister, your sweet heart might be my naughty angel

deekerman commented

2026-02-20 02:16:52 -05:00

Author

Owner

@OffsetMonkey538 commented on GitHub (Dec 31, 2025):

I would still like if face recognition stuff would also be shared, but do agree that different people should be allowed to name people differently for themselves.
I want to be the one that has to deal with all the merging of people and figuring out who they are and having that translate over to everybody.

@OffsetMonkey538 commented on GitHub (Dec 31, 2025): I would still like if face recognition stuff would also be shared, but do agree that different people should be allowed to name people differently for themselves. I want to be the one that has to deal with all the merging of people and figuring out who they are and having that translate over to everybody.

deekerman commented

Author

Owner

@Phlogi commented on GitHub (Dec 31, 2025):

@OffsetMonkey538 Thanks for the valid input — I’ll take it into account as I continue refining and improving the concept here:
https://github.com/immich-app/immich/blob/1bcffa6c39843706f29d256e906ffba7b423ce12/docs/docs/features/better-sharing.md

I’d really appreciate if more people could start reviewing it directly. Bringing feedback into one place would help focus the discussion and avoid losing energy across multiple threads.

@Phlogi commented on GitHub (Dec 31, 2025): @OffsetMonkey538 Thanks for the valid input — I’ll take it into account as I continue refining and improving the concept here: [https://github.com/immich-app/immich/blob/1bcffa6c39843706f29d256e906ffba7b423ce12/docs/docs/features/better-sharing.md](https://github.com/immich-app/immich/blob/1bcffa6c39843706f29d256e906ffba7b423ce12/docs/docs/features/better-sharing.md) I’d really appreciate if more people could start reviewing it directly. Bringing feedback into one place would help focus the discussion and avoid losing energy across multiple threads.

deekerman commented

2026-02-20 02:16:52 -05:00

Author

Owner

@nfay1 commented on GitHub (Jan 2, 2026):

Hi Guys,

I would suggest adding any feature freezes to https://docs.immich.app/developer/pr-checklist to make it clear to people trying to contribute features (especially if they are new to the project).

#24983
#24938

Is there an expected ETA for the design of the new sharing approach so people can start to contribute to it?

Thanks!

@nfay1 commented on GitHub (Jan 2, 2026): Hi Guys, I would suggest adding any feature freezes to https://docs.immich.app/developer/pr-checklist to make it clear to people trying to contribute features (especially if they are new to the project). #24983 #24938 Is there an expected ETA for the design of the new sharing approach so people can start to contribute to it? Thanks!

deekerman commented

2026-02-20 02:16:52 -05:00

Author

Owner

@alextran1502 commented on GitHub (Jan 2, 2026):

Is there an expected ETA for the design of the new sharing approach so people can start to contribute to it?

We plan to work on it this year

@alextran1502 commented on GitHub (Jan 2, 2026): > Is there an expected ETA for the design of the new sharing approach so people can start to contribute to it? We plan to work on it this year

deekerman commented

Author

Owner

@jtagcat commented on GitHub (Jan 3, 2026):

I have used sharing features before, but this time I saw multiple people using it with multiple devices and accounts. Few observations:

Unlike some ecosystems, most users aren't authenticated. Many were asking 'who took this photo' (while the photo was open), 'I want to see photos by X'.
It would be nice to ask the uploader for their name with a textbox before image selection: `What would you like to be called? Upload as <Pink Llama> [Continue]'. Providing a mnemonic default has advantages:
- Encouraging to change it. Allowing pseudonyms (not forcing a passport name tax form declaration, like many platforms signing up ask and train users to give). Allow empty name, allow duplicate names.
- Lessens forensics skills to match SM-XXXX to Llama and iPhone 18 Pro to Rabbit¹. Even when pseudonyms are kept, people can communicate 'ah yes, x is named Woof here'.
- Could also prompt after selecting the first images. 'Uploading in progress. Uploading as'. (or on top of the upload queue with a bright blue button (before the first push it should not be grayed out).
- Saving to cookie with link hash (for any shared use devices where history was cleared) with a long expiry (upload once every few months to the same shared folder).
- A minimal animation to top right where to edit name. Add a checkbox checked by default 'update name on my previously updated photos'.
- Hidden URL encoding extra feature? Prefill the name by link creator.
Phone web app performance was bad. Switching between zooming and navigating required 3-8 retries (up to levels of rage). When standing next to a person, zooming out from 110 to 100 was the workaround.
- The next/back button/region was not visible enough (especially while zoomed in, and not actively adjusting zoom). Gestures rarely worked, laggy (and this also on Android with OS gesture navigation turned off).
- Opening share in app was much better. There currently is no open in app. Tried also logging in to web version in the hopes that it would show up in 'Shared with me' in the app. Had to ask the owner to specifically reshare it.
Can't share forward from app as non-owner. Can't designate other users to make new links or manage the album (description/name included).
Web: pressing back on a photo doesn't scroll the same photo to view in the gallery.
Maybe as a hidden feature in adding #upload to link (not yet another toggle in creating link), point straight to an upload window. Upload request per se.
- Most people found the upload button on their own. Success!
- Some I still explained over.
- With the upload modal open, already uploaded photos and album title should still be visible (discoverable) and modal can be closed.
If the whole phone isn't backed up in the app, adding to albums requires selecting the photos, uploading, waiting for upload to complete, selecting them again, adding to album.
Photos just uploaded to public share can't be removed by the uploadee. I think the name/ident cookie would allow this as well. Small risk here is that when the cookie is cleared/expires, and there is a grown expectation (niche?) to edit.
Onboarding a new user/device, I was surprised how little options there are in the app (good) despite all the features. They could be better organized (one-time setup, UI config, backup-status), submenus in main Settings could be merged.

It seems AI products have hijacked all animal names. ↩︎

@jtagcat commented on GitHub (Jan 3, 2026): I have used sharing features before, but this time I saw multiple people using it with multiple devices and accounts. Few observations: 1. Unlike some ecosystems, most users aren't authenticated. Many were asking 'who took this photo' (while the photo was open), 'I want to see photos by X'. It would be nice to ask the uploader for their name with a textbox before image selection: `What would you like to be called? Upload as \<Pink Llama\> [Continue]'. Providing a mnemonic default has advantages: - Encouraging to change it. Allowing pseudonyms (not forcing a passport name tax form declaration, like many platforms signing up ask and train users to give). Allow empty name, allow duplicate names. - Lessens forensics skills to match SM-XXXX to Llama and iPhone 18 Pro to Rabbit[^ai]. Even when pseudonyms are kept, people can communicate 'ah yes, x is named Woof here'. - Could also prompt after selecting the first images. 'Uploading in progress. Uploading as'. (or on top of the upload queue with a bright blue button (before the first push it should not be grayed out). - Saving to cookie with link hash (for any shared use devices where history was cleared) with a long expiry (upload once every few months to the same shared folder). - A minimal animation to top right where to edit name. Add a checkbox checked by default 'update name on my previously updated photos'. - Hidden URL encoding extra feature? Prefill the name by link creator. 2. Phone web app performance was bad. Switching between zooming and navigating required 3-8 retries (up to levels of rage). When standing next to a person, zooming out from 110 to 100 was the workaround. - The next/back button/region was not visible enough (especially while zoomed in, and not actively adjusting zoom). Gestures rarely worked, laggy (and this also on Android with OS gesture navigation turned off). - Opening share in app was much better. There currently is no open in app. Tried also logging in to web version in the hopes that it would show up in 'Shared with me' in the app. Had to ask the owner to specifically reshare it. 3. Can't share forward from app as non-owner. Can't designate other users to make new links or manage the album (description/name included). 4. Web: pressing back on a photo doesn't scroll the same photo to view in the gallery. 5. Maybe as a hidden feature in adding `#upload` to link (not yet another toggle in creating link), point straight to an upload window. Upload request per se. - Most people found the upload button on their own. Success! - Some I still explained over. - With the upload modal open, already uploaded photos and album title should still be visible (discoverable) and modal can be closed. 6. If the whole phone isn't backed up in the app, adding to albums requires selecting the photos, uploading, waiting for upload to complete, selecting them again, adding to album. 7. Photos just uploaded to public share can't be removed by the uploadee. I think the name/ident cookie would allow this as well. Small risk here is that when the cookie is cleared/expires, and there is a grown expectation (niche?) to edit. 8. Onboarding a new user/device, I was surprised how little options there are in the app (good) despite all the features. They could be better organized (one-time setup, UI config, backup-status), submenus in main Settings could be merged. [^ai]: It seems AI products have hijacked all animal names.

deekerman commented

Author

Owner

@photoserver-pro commented on GitHub (Jan 4, 2026):

After almost a decade using Piwigo, and more recently QNAP QuMagie, I discovered Immich about three weeks ago. I’m genuinely impressed by the overall concept, the mobile experience, and especially the AI-driven features. Immich feels modern, fast, and very thoughtfully designed.

One thing that surprised me, however, is how difficult it currently is to work collaboratively on a large photo archive with a group of people (for example, a family). This topic comes up frequently in GitHub discussions and is often framed as a “sharing” problem.

I’m not fully convinced that this is primarily a sharing problem. I think it’s more fundamentally a permission management problem.

A different perspective: permissions instead of sharing

In many mature systems, collaboration is not solved by sharing individual items, but by defining permissions on objects, with clear inheritance rules.

Typical objects could be:
• folders
• individual assets (photos/videos)
• virtual albums
• smart albums

Permissions are usually applied in a tree-like structure and inherited downward. For example:

2024
├─ January
└─ February

Vacation
├─ Summer USA
└─ Winter Austria

Users could, by default, have access to everything unless explicitly restricted. From there, all related questions become a function of permissions:
• Is the asset visible at all?
• Are metadata visible?
• Are tags visible?
• Does it appear on the map?
• Are people/faces visible?
• Is it included in search results?

In this model, every object has permissions, and everything else follows naturally from that.
Sharing becomes a special case rather than the core mechanism.

Where “sharing” fits in

Sharing still has a place — mainly for:
• users without accounts
• temporary external access
• public or semi-public links

But for internal collaboration (family, household, small groups), permissions and user groups are a more scalable and less repetitive solution.

Immich already supports:
• personal albums
• favorites
• downloads

Those concepts fit very well on top of an object-based permission system. A model based on users + groups + permissions, similar to filesystem ACLs, has proven itself in many domains and scales from a few users to many.

I’m not proposing a concrete implementation here — just offering a perspective that might help reframe the discussion.

From my experience, once permissions are modeled at the object level, many of the current “sharing” edge cases resolve themselves naturally.

@photoserver-pro commented on GitHub (Jan 4, 2026): After almost a decade using Piwigo, and more recently QNAP QuMagie, I discovered Immich about three weeks ago. I’m genuinely impressed by the overall concept, the mobile experience, and especially the AI-driven features. Immich feels modern, fast, and very thoughtfully designed. One thing that surprised me, however, is how difficult it currently is to work collaboratively on a large photo archive with a group of people (for example, a family). This topic comes up frequently in GitHub discussions and is often framed as a “sharing” problem. I’m not fully convinced that this is primarily a sharing problem. I think it’s more fundamentally a permission management problem. A different perspective: permissions instead of sharing In many mature systems, collaboration is not solved by sharing individual items, but by defining permissions on objects, with clear inheritance rules. Typical objects could be: • folders • individual assets (photos/videos) • virtual albums • smart albums Permissions are usually applied in a tree-like structure and inherited downward. For example: 2024 ├─ January └─ February Vacation ├─ Summer USA └─ Winter Austria Users could, by default, have access to everything unless explicitly restricted. From there, all related questions become a function of permissions: • Is the asset visible at all? • Are metadata visible? • Are tags visible? • Does it appear on the map? • Are people/faces visible? • Is it included in search results? In this model, every object has permissions, and everything else follows naturally from that. Sharing becomes a special case rather than the core mechanism. Where “sharing” fits in Sharing still has a place — mainly for: • users without accounts • temporary external access • public or semi-public links But for internal collaboration (family, household, small groups), permissions and user groups are a more scalable and less repetitive solution. Immich already supports: • personal albums • favorites • downloads Those concepts fit very well on top of an object-based permission system. A model based on users + groups + permissions, similar to filesystem ACLs, has proven itself in many domains and scales from a few users to many. I’m not proposing a concrete implementation here — just offering a perspective that might help reframe the discussion. From my experience, once permissions are modeled at the object level, many of the current “sharing” edge cases resolve themselves naturally.

deekerman commented

Author

Owner

@ojsef39 commented on GitHub (Jan 4, 2026):

I also want to add my use case here since i saw similar remarks but not exactly what i had in mind.

So what i would love to see as well is some kind of shared album/library that i can share with multiple users (this should also share stuff like faces, etc like others mentioned already) maybe bound to a role so its easily configurable via oAuth which user can access which libraries.

What am i trying to achieve? I really don't want to completely move away from nextcloud, so i thought I could have one shared library for my whole family and just mount the same folder into a group/teamfolder in nextcloud but after trying a lot of things, i dont think this is really possible right now.
Thanks for reading my two cents on this :)

@ojsef39 commented on GitHub (Jan 4, 2026): I also want to add my use case here since i saw similar remarks but not exactly what i had in mind. So what i would love to see as well is some kind of shared album/library that i can share with multiple users (this should also share stuff like faces, etc like others mentioned already) maybe bound to a role so its easily configurable via oAuth which user can access which libraries. What am i trying to achieve? I really don't want to completely move away from nextcloud, so i thought I could have one shared library for my whole family and just mount the same folder into a group/teamfolder in nextcloud but after trying a lot of things, i dont think this is really possible right now. Thanks for reading my two cents on this :)

deekerman commented

Author

Owner

@abonhote commented on GitHub (Jan 5, 2026):

After trying to get my memories working again, I came across this feature request. However, I can't see any mention of "memory" or "memories" - is this in scope?

@abonhote commented on GitHub (Jan 5, 2026): After trying to get my memories working again, I came across this feature request. However, I can't see any mention of "memory" or "memories" - is this in scope?

deekerman commented

Author

Owner

@timonrieger commented on GitHub (Jan 5, 2026):

After trying to get my memories working again, I came across this feature request. However, I can't see any mention of "memory" or "memories" - is this in scope?

The memory enhancement requests are mostly unrelated to this discussion. see https://github.com/immich-app/immich/discussions?discussions_q=is%3Aopen+memories for existing requests

@timonrieger commented on GitHub (Jan 5, 2026): > After trying to get my memories working again, I came across this feature request. However, I can't see any mention of "memory" or "memories" - is this in scope? The memory enhancement requests are mostly unrelated to this discussion. see https://github.com/immich-app/immich/discussions?discussions_q=is%3Aopen+memories for existing requests

deekerman commented

Author

Owner

@antonclaeys commented on GitHub (Jan 6, 2026):

We use Immich for project photos: one album per project, shared internally so all employees can view and upload. We also collaborate with subcontractors and want them to be able to view and add photos to a project album, but not delete or remove any photos.

Today the only safe option is a public share link with uploads enabled, but only the album creator/owner can create that link, which breaks team workflows. Feature request: allow album editors (or a dedicated role) to create/manage share links for an album, and/or add a “contributor” permission for users that can upload but cannot delete.

@antonclaeys commented on GitHub (Jan 6, 2026): We use Immich for project photos: one album per project, shared internally so all employees can view and upload. We also collaborate with subcontractors and want them to be able to view and add photos to a project album, but not delete or remove any photos. Today the only safe option is a public share link with uploads enabled, but only the album creator/owner can create that link, which breaks team workflows. Feature request: allow album editors (or a dedicated role) to create/manage share links for an album, and/or add a “contributor” permission for users that can upload but cannot delete.

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 9, 2026):

I think I am here in the opposition to some of the sharing requests made; I see the use in explicitly sharing names for persons, but this also might be a problem in extended family use cases where maybe I do not want leak the information of who knows who.

I suggest splitting the concepts of per asset data and per user data and share them independently, i.e. the face detection and thumbnail belong to the asset while the person to face matching is done per user (with the option to share recognized persons with other).

To make this even more useful persons should also be groupable, maybe via a tag like semantic of family/lastname/firstname or colleague/company/fullname. additionally an option should be given to share a person with a suggested name instead of the original name, because circle/nickname made be the correct name for me, but someone else will only know them by their official name

The overall concept of permissions as suggested here would be rather useful to complete this, especially after the data sources are properly split

For tags this permission management becomes even harder because with those it's harder to see if they are asset or user based. But they should be shareable in an explicit way too, because I for example tag every file with an upload identifier and their path but that's not really needed for anyone else to see, while the information of people/abc would be useful for pictures without faces.

maybe having persons as tags on the recognized faces with a wellknown prefix would be a usefulness solution to basically fix multiple of these problems at once.

As for the global deduplication and asset sharing I could see an asset -> data split and maybe create the IDs based on the uploading users I'd and point to a data_asset identified by its hash but this might break the current library and storage path features, so I really don't have a firm opinion on this.

@JensHeinrich commented on GitHub (Jan 9, 2026): I think I am here in the opposition to some of the sharing requests made; I see the use in explicitly sharing names for persons, but this also might be a problem in extended family use cases where maybe I do not want leak the information of who knows who. I suggest splitting the concepts of per asset data and per user data and share them independently, i.e. the face detection and thumbnail belong to the asset while the person to face matching is done per user (with the option to share recognized persons with other). To make this even more useful persons should also be groupable, maybe via a tag like semantic of `family/lastname/firstname` or `colleague/company/fullname`. additionally an option should be given to share a person with a suggested name instead of the original name, because `circle/nickname` made be the correct name for me, but someone else will only know them by their official name The overall concept of permissions as suggested [here](https://github.com/immich-app/immich/issues/12614#issuecomment-3708354185) would be rather useful to complete this, especially after the data sources are properly split For tags this permission management becomes even harder because with those it's harder to see if they are asset or user based. But they should be shareable in an explicit way too, because I for example tag every file with an upload identifier and their path but that's not really needed for anyone else to see, while the information of `people/abc` would be useful for pictures without faces. maybe having persons as tags on the recognized faces with a wellknown prefix would be a usefulness solution to basically fix multiple of these problems at once. As for the global deduplication and asset sharing I could see an asset -> data split and maybe create the IDs based on the uploading users I'd and point to a data_asset identified by its hash but this might break the current library and storage path features, so I really don't have a firm opinion on this.

deekerman commented

Author

Owner

@Ra72xx commented on GitHub (Jan 9, 2026):

Please don't make too much of a science out of this.

I personally would be glad with a intuitive sharing logic "to whom I share a photo, I also want to share all metadata derived from it". For privacy reasons, maybe add an option "share picture without metadata". Even now, many metadata tags are already shared with the picture, they are only not really easily accessible from the ui.

@Ra72xx commented on GitHub (Jan 9, 2026): Please don't make too much of a science out of this. I personally would be glad with a intuitive sharing logic "to whom I share a photo, I also want to share all metadata derived from it". For privacy reasons, maybe add an option "share picture without metadata". Even now, many metadata tags are already shared with the picture, they are only not really easily accessible from the ui.

deekerman commented

Author

Owner

@Suppi123 commented on GitHub (Jan 9, 2026):

I agree with @Ra72xx

A simple selection for the metadata would suffice.

In addition, a function that runs facial recognition (and perhaps also context search) on images that have been shared with me would be helpful. Then it would also match directly with the people stored in my profile. Of course, this would cost resources (models analyze images multiple times under certain circumstances), but I think these costs are acceptable, as it would be a simple and robust solution.

@Suppi123 commented on GitHub (Jan 9, 2026): I agree with @Ra72xx A simple selection for the metadata would suffice. In addition, a function that runs facial recognition (and perhaps also context search) on images that have been shared with me would be helpful. Then it would also match directly with the people stored in my profile. Of course, this would cost resources (models analyze images multiple times under certain circumstances), but I think these costs are acceptable, as it would be a simple and robust solution.

deekerman commented

Author

Owner

@Samurai-Panda commented on GitHub (Jan 9, 2026):

I somewhat agree with both Ra72xx and Suppi123. To be able to select which metadata to share per album would be ultimate.

But I I think we're already so close, Editors or Viewer is a great start. As it is now though there's no difference in permissions between the two, besides being able to upload to album. Editors should be able to view and edit the shared photos (tags and faces included). viewers should be able to view and comment.

@Samurai-Panda commented on GitHub (Jan 9, 2026): I somewhat agree with both Ra72xx and Suppi123. To be able to select which metadata to share per album would be ultimate. But I I think we're already so close, Editors or Viewer is a great start. As it is now though there's no difference in permissions between the two, besides being able to upload to album. Editors should be able to view and edit the shared photos (**tags and faces included**). viewers should be able to view and comment.

deekerman commented

Author

Owner

@photoserver-pro commented on GitHub (Jan 9, 2026):

From my experience with other photo platforms (e.g., Piwigo), I tend to think this topic might become much simpler if we frame it primarily as a “classic” permission model at the asset level.

In other words: the core question is usually just “is a user allowed to see this photo or not?”
If a user has permission to view an asset, then showing the related metadata (GPS, tags, people, etc.) feels like the natural default. And if the user is not permitted to view the asset, then none of that information would be exposed either.

The same principle could apply consistently across objects like folders, albums, smart albums, external libraries, etc. There’s typically an owner/creator of an asset, and then additional permissions granted to other users or groups.

With that in mind, I’m curious about real-world use cases where we would intentionally allow someone to see the photo but not certain metadata (or vice versa). My intuition is that in most shared-library scenarios, once you can see an image, you implicitly can access its metadata as well.

In that sense, “sharing” might be best treated as a separate edge case for non-registered users (public/shared links), whereas everything inside the system could be handled via normal user/group permissions.

@photoserver-pro commented on GitHub (Jan 9, 2026): From my experience with other photo platforms (e.g., Piwigo), I tend to think this topic might become much simpler if we frame it primarily as a “classic” permission model at the asset level. In other words: the core question is usually just “is a user allowed to see this photo or not?” If a user has permission to view an asset, then showing the related metadata (GPS, tags, people, etc.) feels like the natural default. And if the user is not permitted to view the asset, then none of that information would be exposed either. The same principle could apply consistently across objects like folders, albums, smart albums, external libraries, etc. There’s typically an owner/creator of an asset, and then additional permissions granted to other users or groups. With that in mind, I’m curious about real-world use cases where we would intentionally allow someone to see the photo but not certain metadata (or vice versa). My intuition is that in most shared-library scenarios, once you can see an image, you implicitly can access its metadata as well. In that sense, “sharing” might be best treated as a separate edge case for non-registered users (public/shared links), whereas everything inside the system could be handled via normal user/group permissions.

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 9, 2026):

If a user has permission to view an asset, then showing the related metadata (GPS, tags, people, etc.) feels like the natural default. And if the user is not permitted to view the asset, then none of that information would be exposed either.

I think so too except for the generated metadata of the person.

With that in mind, I’m curious about real-world use cases where we would intentionally allow someone to see the photo but not certain metadata (or vice versa). My intuition is that in most shared-library scenarios, once you can see an image, you implicitly can access its metadata as well.

The old school uncle that should not see the new name of someone in a different family branch for example.
Or maybe parents should be able to see the face of the new boyfriend in the group picture from the inter school exchange, but as pictures are only assigned to persons after a certain threshold has been met, this might leak the daughter having a new boyfriend unintentionally...
Or maybe I tag my best friend as "stupid donkey" in my pictures for fun, but it really should not be how he is named by the family.

(And yes obviously we are talking edge cases here)

@JensHeinrich commented on GitHub (Jan 9, 2026): > If a user has permission to view an asset, then showing the related metadata (GPS, tags, people, etc.) feels like the natural default. And if the user is not permitted to view the asset, then none of that information would be exposed either. I think so too except for the generated metadata of the person. > With that in mind, I’m curious about real-world use cases where we would intentionally allow someone to see the photo but not certain metadata (or vice versa). My intuition is that in most shared-library scenarios, once you can see an image, you implicitly can access its metadata as well. The old school uncle that should not see the new name of someone in a different family branch for example. Or maybe parents should be able to see the face of the new boyfriend in the group picture from the inter school exchange, but as pictures are only assigned to persons after a certain threshold has been met, this might leak the daughter having a new boyfriend unintentionally... Or maybe I tag my best friend as "stupid donkey" in my pictures for fun, but it really should not be how he is named by the family. (And yes obviously we are talking edge cases here)

deekerman commented

Author

Owner

@Ra72xx commented on GitHub (Jan 9, 2026):

This really seams like an edge case indeed. For me, the most sensitive content is the picture itself. (It might be sensible to remove some stuff like gps position and names when publicly sharing photos, but I don't know if this is an intended use case? I don't do public sharing, so I cannot really judge that.)

BTW, in many cases metadata like gps is contained in the picture itself in form of EXIF tags. These tags would have to be removed directly from the file content when sharing in this case, too.

@Ra72xx commented on GitHub (Jan 9, 2026): This really seams like an edge case indeed. For me, the most sensitive content is the picture itself. (It might be sensible to remove some stuff like gps position and names when publicly sharing photos, but I don't know if this is an intended use case? I don't do public sharing, so I cannot really judge that.) BTW, in many cases metadata like gps is contained in the picture itself in form of EXIF tags. These tags would have to be removed directly from the file content when sharing in this case, too.

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 9, 2026):

BTW, in many cases metadata like gps is contained in the picture itself in form of EXIF tags. These tags would have to be removed directly from the file content when sharing in this case, too.

That's why I originally suggested splitting per asset and per user data

I suggest splitting the concepts of per asset data and per user data and share them independently, i.e. the face detection and thumbnail belong to the asset while the person to face matching is done per user (with the option to share recognized persons with other).

Because even if the face is marked as face the mapping to a person is done in the context of all assets of a user and not the asset alone

@JensHeinrich commented on GitHub (Jan 9, 2026): > BTW, in many cases metadata like gps is contained in the picture itself in form of EXIF tags. These tags would have to be removed directly from the file content when sharing in this case, too. That's why I originally suggested splitting per asset and per user data > I suggest splitting the concepts of per asset data and per user data and share them independently, i.e. the face detection and thumbnail belong to the asset while the person to face matching is done per user (with the option to share recognized persons with other). Because even if the face is marked as face the mapping to a person is done in the context of all assets of a user and not the asset alone

deekerman commented

Author

Owner

@Ra72xx commented on GitHub (Jan 10, 2026):

But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata?

My concern is that making this functionality too complicated could mean that the implementation will take too much time. And currently sharing is simply too limited for a "friends & family" photo server because of the missing metadata sharing. I would rather have a fast implementation of a simple solution which covers >90% of the use cases.

However, I don't know the developpers' stance on this...

@Ra72xx commented on GitHub (Jan 10, 2026): But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata? My concern is that making this functionality too complicated could mean that the implementation will take too much time. And currently sharing is simply too limited for a "friends & family" photo server because of the missing metadata sharing. I would rather have a fast implementation of a simple solution which covers >90% of the use cases. However, I don't know the developpers' stance on this...

deekerman commented

Author

Owner

@GenieTim commented on GitHub (Jan 10, 2026):

I fully agree that the current shared metadata is not sufficient and a simple and fast solution would be highly appreciated. To have a fast solution, metadata such as the GPS data should be included in all cases (given how good OS Int and Geoguessers are, omitting it might not be that big a deal anyway).

I believe an important point that's missed often when it comes to faces and tags is that people might use them differently: in the same family, you may have the daughter tagging faces with "me", "mom", "dad", "aunt", and the mother tagging faces with "daughter", "me", "love", "sister".¹ Similarly for the tags of photos: a "holiday" might be a "work trip" for the partner, "favorite place", "favorite human" tags are personal, a photo of a family member falling might be "funny" for some and "mean" for others, and even in the same family, users may use different languages for the tags.

If that's allowed and shown to everyone you share the photos with, their tag and faces overview will be cluttered with duplicates and/or tags and faces they don't care about.

For the "simple solution" to not annoy anyone, it therefore must:

In the case of faces: allow every user to give its own name to every face. The privacy question is only if whether the name given by the photo sharing person is applied to faces that have not been named in the recipients face library.

In the case of tags: the solutions here could get arbitrarily complicated, from linking tags, to renaming them one-sided to sharing them only once when sharing the album. In my "Immich-architecture-unaware" expectation, I would guess that a simple solution without the clutter could be to just have sections in the tag library, i.e., "Your tags", "Tags shared by ...", "...". When looking at a tag that exists in multiple locations (your library, shared album, ...), there could be a simple switch to include/exclude the "external" images. Again, I see much potential here to make things arbitrarily complicated in more steps, this is just my humble view of what I would guess would fit the 90% use case.

¹I assume more than 10% do this, requiring the handling in the 90% use case, due to how people name their contacts in their phones.

@GenieTim commented on GitHub (Jan 10, 2026): I fully agree that the current shared metadata is not sufficient and a simple and fast solution would be highly appreciated. To have a fast solution, metadata such as the GPS data should be included in all cases (given how good OS Int and Geoguessers are, omitting it might not be that big a deal anyway). I believe an important point that's missed often when it comes to faces and tags is that people might use them differently: in the same family, you may have the daughter tagging faces with "me", "mom", "dad", "aunt", and the mother tagging faces with "daughter", "me", "love", "sister".¹ Similarly for the tags of photos: a "holiday" might be a "work trip" for the partner, "favorite place", "favorite human" tags are personal, a photo of a family member falling might be "funny" for some and "mean" for others, and even in the same family, users may use different languages for the tags. If that's allowed and shown to everyone you share the photos with, their tag and faces overview will be cluttered with duplicates and/or tags and faces they don't care about. For the "simple solution" to not annoy anyone, it therefore must: In the case of *faces*: allow every user to give its own name to every face. The privacy question is only if whether the name given by the photo sharing person is applied to faces that have not been named in the recipients face library. In the case of *tags*: the solutions here could get arbitrarily complicated, from linking tags, to renaming them one-sided to sharing them only once when sharing the album. In my "Immich-architecture-unaware" expectation, I would guess that a simple solution without the clutter could be to just have sections in the tag library, i.e., "Your tags", "Tags shared by ...", "...". When looking at a tag that exists in multiple locations (your library, shared album, ...), there could be a simple switch to include/exclude the "external" images. Again, I see much potential here to make things arbitrarily complicated in more steps, this is just my humble view of what I would guess would fit the 90% use case. --- ¹I assume more than 10% do this, requiring the handling in the 90% use case, due to how people name their contacts in their phones.

deekerman commented

Author

Owner

@Ra72xx commented on GitHub (Jan 10, 2026):

Good ideas.
Maybe my use case is to simple, it's only me actively curating the photo collection, so I decide on the naming scheme of faces (which is, unpersonally, first name - last name ;-) , which could be agreed upon by all users). This might very well different for other use cases.
I guess Immich does internally not classify faces by the user-given name, but by some kind of uuid. Maybe you share only this uuid and the naming is left to the user to whom the picture is shared, defaulting to the name the picture's owner has decided upon?
So even this seemingly simple face sharing has its own share of problematic points, without integrating any further fine-grained permission system.

@Ra72xx commented on GitHub (Jan 10, 2026): Good ideas. Maybe my use case is to simple, it's only me actively curating the photo collection, so I decide on the naming scheme of faces (which is, unpersonally, first name - last name ;-) , which could be agreed upon by all users). This might very well different for other use cases. I guess Immich does internally not classify faces by the user-given name, but by some kind of uuid. Maybe you share only this uuid and the naming is left to the user to whom the picture is shared, defaulting to the name the picture's owner has decided upon? So even this seemingly simple face sharing has its own share of problematic points, without integrating any further fine-grained permission system.

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 10, 2026):

I guess Immich does internally not classify faces by the user-given name, but by some kind of uuid.

If I guess correctly from faces being tagged without being assigned to a person there seems to be a person/face split anyway

So being able to share person UUID to asset.face mappings as a dedicated share option would be the best solution in regards to privacy and the more logical one in regard to where the data belongs (with the mapping belonging to a user while the faces belong to an asset)

But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata?

TBF I have quite a lot of trans people in my circles so me linking their face in school time off picture to their current face should not imply me sharing this information with other friends they have not come out to (yet)
But I might still go bowling with those people and hence they were on my wedding without recognising them...

Same goes for all communities where not everyone might no someone with and without their mask, ie Cosplayers or furries. For my mother the person with and without the mask might be two different people, but I still would like to find all of their pictures when searching for them.
This probably could also be partly mitigated by having nestable persons eg friends/firstname lastname (furry name)/furry name and friends/firstname lastname (furry name)/firstname lastname, and sharing only those separately without including the hierarchy, which would require the face - person split again

@JensHeinrich commented on GitHub (Jan 10, 2026): > I guess Immich does internally not classify faces by the user-given name, but by some kind of uuid. If I guess correctly from faces being tagged without being assigned to a person there seems to be a person/face split anyway So being able to share person UUID to asset.face mappings as a dedicated share option would be the best solution in regards to privacy and the more logical one in regard to where the data belongs (with the mapping belonging to a user while the faces belong to an asset) > But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata? TBF I have quite a lot of trans people in my circles so me linking their face in school time off picture to their current face should not imply me sharing this information with other friends they have not come out to (yet) But I might still go bowling with those people and hence they were on my wedding without recognising them... Same goes for all communities where not everyone might no someone with and without their mask, ie Cosplayers or furries. For my mother the person with and without the mask might be two different people, but I still would like to find all of their pictures when searching for them. This probably could also be partly mitigated by having nestable persons eg `friends/firstname lastname (furry name)/furry name` and `friends/firstname lastname (furry name)/firstname lastname`, and sharing only those separately without including the hierarchy, which would require the face - person split again

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 10, 2026):

In the case of tags: the solutions here could get arbitrarily complicated, from linking tags, to renaming them one-sided to sharing them only once when sharing the album. In my "Immich-architecture-unaware" expectation, I would guess that a simple solution without the clutter could be to just have sections in the tag library, i.e., "Your tags", "Tags shared by ...", "...". When looking at a tag that exists in multiple locations (your library, shared album, ...), there could be a simple switch to include/exclude the "external" images. Again, I see much potential here to make things arbitrarily complicated in more steps, this is just my humble view of what I would guess would fit the 90% use case.

I feel like especially sharing tags (and optionally all assets assigned to them) or setting permissions at a tag level would also be useful.
I might want no one except me to see as assets tagged with presents/wip while still sharing the workshop/wip assets with my brother sharing the same workshop

@JensHeinrich commented on GitHub (Jan 10, 2026): > In the case of _tags_: the solutions here could get arbitrarily complicated, from linking tags, to renaming them one-sided to sharing them only once when sharing the album. In my "Immich-architecture-unaware" expectation, I would guess that a simple solution without the clutter could be to just have sections in the tag library, i.e., "Your tags", "Tags shared by ...", "...". When looking at a tag that exists in multiple locations (your library, shared album, ...), there could be a simple switch to include/exclude the "external" images. Again, I see much potential here to make things arbitrarily complicated in more steps, this is just my humble view of what I would guess would fit the 90% use case. I feel like especially sharing tags (and optionally all assets assigned to them) or setting permissions at a tag level would also be useful. I might want no one except me to see as assets tagged with `presents/wip` while still sharing the `workshop/wip` assets with my brother sharing the same workshop

deekerman commented

Author

Owner

@SirBoomBoom commented on GitHub (Jan 10, 2026):

As a non-contributor I feel stronger than probably appropriate about Immich internally tracking all faces in some kind of centralized, single collection with UUIDs as identifiers. Gives my brain those warm fuzzies knowing I'm redundantly processing and storing data needlessly :) Plus, by only processing the faces on a photo once instead of for every person the photo is shared with, it feels like that would cut back on a lot of annoying mismatches and just repetetive work in general for everyone involved. And with that as a core, it seems like it should be fairly trivial to have some kind of mapping collection of UUID->Personalized name for any given user. Only tricky parts that immediately jumps out at me would be around faces that are in other people's photos but not yours the first time you take a photo with them in it. Especially when the count falls below whatever your threshold is for bothering to identify people.

The security concerns around faces being backed by the same internal UUID and getting compromised hold a lot less weight to me, mostly because if your data is compromised like that there is absolutely nothing stopping a person (or their own Immich instance even) from looking at photos of 'Goofball Brother', 'Bubba Smith', 'Stupid Ex' and immediately identifying them all as the same person, despite them having different IDs. From a design perspective I get it, it's always a good idea to think about and try and implement secure code, but realistically in this case the photos themselves are the true identifiers and no amount of different names under the hood is going to stop someone from connecting people if they've compromised your collection.

The much more interesting question (I think) is around sharing the names people have chosen for a person, as well as managing if people can edit those names or not. Normally speaking for me personally, if I'm sharing my photos with someone I'd want them to see the names I used for people by default, with Immich displaying their own personalized versions if applicable (if I don't want someone I'm sharing with to see the name I've chosen I'd just rename them.) But I also tend to be fairly liberal with links to shared albums for friends and family who can't be bothered to create an account just to view said photos, and I absolutely want them to be able to see and query based off faces/metadata, which would have to default to mine given their lack of account. Also much of the time I'd want them to be able to edit the names of faces themselves. I'd honestly much rather deal with the rare needing to go back and lockdown permissions because someone's being immature than personally name every person I don't really know at an event when I can offload that to the people themselves =P (Obviously not saying that needs to be the default, just that I want the option). I would probably lean towards not letting them merge people together though, just cause that would be much more annoying to fix than renaming people. Or at least not without explicit permissions to do so, but that I'm okay being limited to actual account permissions. (Like we got my grandparents integrated a while back and my grandma has been steadily working her way through all the old family photos naming, tagging and dealing with how alike we all looked as kids across the generations and I desperately wish it was being applied to my photos too lol)

All this being said, I can think of plenty of reasons where you wouldn't want the people you are sharing photos with to see the names you've chosen. In which case I can think of a couple of possible solutions:

Simplest option, show the names on faces of people they've already named and treat all other faces like Immich normally does when scanning in new photos, allowing the user to provide their own name to the face. I like that this both feels straightforward to implement, is easy to understand, and hard to mess up when sharing.
Alternatively, allow you to tag people twice - 'Full Name' and 'Nickname' - where 'nicknames' are what you see but 'full names' are what are displayed when you share photos. You could obviously take this farther and design hierarchies/tag groups/complex sharing rules, but I suspect limiting it to just 2 will cover 99.9+% of all use cases, be much easier to implement, as well as be easier to understand and use correctly for non-technical users.
Go all in on some kind of complex user management system allowing you to create complex rules and associations (e.g. 'name is X, unless shared with family, then name is Y, but if extended family present then name is Z' kinda thing). While this approach would be really cool and cover almost every conceivable use case if done well, I'd be more worried about it taking forever to actually implement and collapsing under its own weight. Plus it'll require some robust hand holding for most users to truly take advantage of.

I'd honestly be very happy with solution 1, as I don't know if I'd ever use option 2, but I think option 2 is actually my favorite from a mostly uninformed cost/benefit standpoint ;-) Also, a minor tangent, but if someone shares photos with me and I do get to see their name data, it would be nice to be given the option to adopt their name instead of mine when collisions exist. Specifically, I'm thinking of cases where I've got names like "Cousin Riley's 2023 BF", or "Tim's D&D Friend". Basically the people who show up in my photos sporadically but whose names I can never remember cause I don't really know them :) I've less an idea how that could be implemented well, but would be nice to have.

(And as long as we are making wishes, I'd also LOVE to be able to make albums based off queries/metadata and share those. Being able to make an album of "Brother's Family" or "Friend X" and share them once without needing to constantly remember to add photos of them every time we get together would be awesome)

@SirBoomBoom commented on GitHub (Jan 10, 2026): As a non-contributor I feel stronger than probably appropriate about Immich internally tracking all faces in some kind of centralized, single collection with UUIDs as identifiers. Gives my brain those warm fuzzies knowing I'm redundantly processing and storing data needlessly :) Plus, by only processing the faces on a photo once instead of for every person the photo is shared with, it feels like that would cut back on a lot of annoying mismatches and just repetetive work in general for everyone involved. And with that as a core, it seems like it should be fairly trivial to have some kind of mapping collection of UUID->Personalized name for any given user. Only tricky parts that immediately jumps out at me would be around faces that are in other people's photos but not yours the first time you take a photo with them in it. Especially when the count falls below whatever your threshold is for bothering to identify people. The security concerns around faces being backed by the same internal UUID and getting compromised hold a lot less weight to me, mostly because if your data is compromised like that there is absolutely nothing stopping a person (or their own Immich instance even) from looking at photos of 'Goofball Brother', 'Bubba Smith', 'Stupid Ex' and immediately identifying them all as the same person, despite them having different IDs. From a design perspective I get it, it's always a good idea to think about and try and implement secure code, but realistically in this case the photos themselves are the true identifiers and no amount of different names under the hood is going to stop someone from connecting people if they've compromised your collection. The much more interesting question (I think) is around sharing the names people have chosen for a person, as well as managing if people can edit those names or not. Normally speaking for me personally, if I'm sharing my photos with someone I'd want them to see the names I used for people by default, with Immich displaying their own personalized versions if applicable (if I don't want someone I'm sharing with to see the name I've chosen I'd just rename them.) But I also tend to be fairly liberal with links to shared albums for friends and family who can't be bothered to create an account just to view said photos, and I absolutely want them to be able to see and query based off faces/metadata, which would have to default to mine given their lack of account. Also much of the time I'd want them to be able to edit the names of faces themselves. I'd honestly much rather deal with the rare needing to go back and lockdown permissions because someone's being immature than personally name every person I don't really know at an event when I can offload that to the people themselves =P (Obviously not saying that needs to be the default, just that I want the option). I would probably lean towards not letting them merge people together though, just cause that would be much more annoying to fix than renaming people. Or at least not without explicit permissions to do so, but that I'm okay being limited to actual account permissions. (Like we got my grandparents integrated a while back and my grandma has been steadily working her way through all the old family photos naming, tagging and dealing with how alike we all looked as kids across the generations and I desperately wish it was being applied to my photos too lol) All this being said, I can think of plenty of reasons where you wouldn't want the people you are sharing photos with to see the names you've chosen. In which case I can think of a couple of possible solutions: 1. Simplest option, show the names on faces of people they've already named and treat all other faces like Immich normally does when scanning in new photos, allowing the user to provide their own name to the face. I like that this both feels straightforward to implement, is easy to understand, and hard to mess up when sharing. 2. Alternatively, allow you to tag people twice - 'Full Name' and 'Nickname' - where 'nicknames' are what you see but 'full names' are what are displayed when you share photos. You could obviously take this farther and design hierarchies/tag groups/complex sharing rules, but I suspect limiting it to just 2 will cover 99.9+% of all use cases, be much easier to implement, as well as be easier to understand and use correctly for non-technical users. 3. Go all in on some kind of complex user management system allowing you to create complex rules and associations (e.g. 'name is X, unless shared with family, then name is Y, but if extended family present then name is Z' kinda thing). While this approach would be really cool and cover almost every conceivable use case if done well, I'd be more worried about it taking forever to actually implement and collapsing under its own weight. Plus it'll require some robust hand holding for most users to truly take advantage of. I'd honestly be very happy with solution 1, as I don't know if I'd ever use option 2, but I think option 2 is actually my favorite from a mostly uninformed cost/benefit standpoint ;-) Also, a minor tangent, but if someone shares photos with me and I do get to see their name data, it would be nice to be given the option to adopt their name instead of mine when collisions exist. Specifically, I'm thinking of cases where I've got names like "Cousin Riley's 2023 BF", or "Tim's D&D Friend". Basically the people who show up in my photos sporadically but whose names I can never remember cause I don't really know them :) I've less an idea how that could be implemented well, but would be nice to have. (And as long as we are making wishes, I'd also LOVE to be able to make albums based off queries/metadata and share those. Being able to make an album of "Brother's Family" or "Friend X" and share them once without needing to constantly remember to add photos of them every time we get together would be awesome)

deekerman commented

Author

Owner

@tristanjodsalz commented on GitHub (Jan 10, 2026):

But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata?

TBF I have quite a lot of trans people in my circles so me linking their face in school time off picture to their current face should not imply me sharing this information with other friends they have not come out to (yet) But I might still go bowling with those people and hence they were on my wedding without recognising them...

Is the problem that you don’t want to leak the name of a person or that you don’t want to leak that two faces from two pictures are the same person?

@tristanjodsalz commented on GitHub (Jan 10, 2026): > > But if you have privacy concerns with somebody you share a picture with, why would you share a picture with him/her at all? Or maybe you have to create a special curated album for this person including photo versions with manual redacted metadata? > > TBF I have quite a lot of trans people in my circles so me linking their face in school time off picture to their current face should not imply me sharing this information with other friends they have not come out to (yet) But I might still go bowling with those people and hence they were on my wedding without recognising them... Is the problem that you don’t want to leak the name of a person or that you don’t want to leak that two faces from two pictures are the same person?

deekerman commented

Author

Owner

@kevincox commented on GitHub (Jan 10, 2026):

The problem is the face clustering. Since this uses information from multiple photos you can learn about other photos if it uses all images in the instance rather than only all images that you have access to. A very simple attack looks like this:

Find two photos of someone that are just different enough that Immich wouldn't cluster them together.
Upload them.
Check if they were grouped together.

If they are clustered you know that there are other photos of this person in the set of photos used in clustering.

This is one of those things that isn't an issue for most uses of Immich with trusted users but can be very dangerous for people in rarer situations. However since effectively warning about this would be very hard it seems best that unless the clustering data (and probably labels at the same time) is shared explicitly the clustering should be performed separately per-user.

Computationally clustering isn't very expensive. Most processing steps that only take single images as input could still be shared. So I wouldn't be worried about the computational cost. The only real downside is that when not shared users would need to merge face groups and label separately.

@kevincox commented on GitHub (Jan 10, 2026): The problem is the face clustering. Since this uses information from multiple photos you can learn about other photos if it uses all images in the instance rather than only all images that you have access to. A very simple attack looks like this: 1. Find two photos of someone that are just different enough that Immich wouldn't cluster them together. 2. Upload them. 3. Check if they were grouped together. If they are clustered you know that there are other photos of this person in the set of photos used in clustering. This is one of those things that isn't an issue for most uses of Immich with trusted users but can be very dangerous for people in rarer situations. However since effectively warning about this would be very hard it seems best that unless the clustering data (and probably labels at the same time) is shared explicitly the clustering should be performed separately per-user. Computationally clustering isn't very expensive. Most processing steps that only take single images as input could still be shared. So I wouldn't be worried about the computational cost. The only real downside is that when not shared users would need to merge face groups and label separately.

deekerman commented

Author

Owner

@alex-pub commented on GitHub (Jan 10, 2026):

While I'd love a comprehensive permissions system with decoupled albums, images, faces and tags - with sensible sharing defaults - it is a can of worms that not even companies with endless resources haven't figured out how to contain, so suggesting this for a FOSS project is essentially guaranteeing that it will never be done.

I still think that a simple multi-account support with all-or-nothing sharing is probably the easiest to implement. Yes, it would imply multiple reprocessing of everything not embedded in the images themselves, but face tagging is really not that computationally expensive to do it multiple times (I don't even bother to run mine GPU-accelerated). This, after all, seems like how majority here are dealing with the issue with intra-family sharing anyway.

@alex-pub commented on GitHub (Jan 10, 2026): While I'd love a comprehensive permissions system with decoupled albums, images, faces and tags - with sensible sharing defaults - it is a can of worms that not even companies with endless resources haven't figured out how to contain, so suggesting this for a FOSS project is essentially guaranteeing that it will never be done. I still think that a simple multi-account support with all-or-nothing sharing is probably the easiest to implement. Yes, it would imply multiple reprocessing of everything not embedded in the images themselves, but face tagging is really not that computationally expensive to do it multiple times (I don't even bother to run mine GPU-accelerated). This, after all, seems like how majority here are dealing with the issue with intra-family sharing anyway.

deekerman commented

Author

Owner

@darktorana commented on GitHub (Jan 10, 2026):

I feel people aren't reading previous messages, there are solutions to most of the problems that people are pointing out.

Also the edge cases for sensitive images (I saw examples of trans that haven't come out and furries) seem like extreme edge cases where the simple solution is to just not share those sensitive images?

Sharing face data is what most people in this thread are asking for. If someone doesn't want it, then having a 'family Mode' and 'public Mode' where the family mode shares data and the public mode (more or less how it works now) doesn't.

But mostly I'm commenting to remind everyone that the Devs already asked people to stop posting agreements or conversations in this chat, as it spams everyone.
They asked to react to the feature or a specific post :)

@darktorana commented on GitHub (Jan 10, 2026): I feel people aren't reading previous messages, there are solutions to most of the problems that people are pointing out. Also the edge cases for sensitive images (I saw examples of trans that haven't come out and furries) seem like extreme edge cases where the simple solution is to just not share those sensitive images? Sharing face data is what most people in this thread are asking for. If someone doesn't want it, then having a 'family Mode' and 'public Mode' where the family mode shares data and the public mode (more or less how it works now) doesn't. But mostly I'm commenting to remind everyone that the Devs already asked people to stop posting agreements or conversations in this chat, as it spams everyone. They asked to react to the feature or a specific post :)

deekerman commented

Author

Owner

@JensHeinrich commented on GitHub (Jan 10, 2026):

Is the problem that you don’t want to leak the name of a person or that you don’t want to leak that two faces from two pictures are the same person?

More the latter, especially if the normal face recognition would not be able to match them

Also the edge cases for sensitive images (I saw examples of trans that haven't come out and furries) seem like extreme edge cases where the simple solution is to just not share those sensitive images?

The point is not the picture being sensitive, but the clustering of multiple faces being the problem.
If you have a person with a full fur suit and without the fur suit you will probably not be able to guess they are the same person unless this meta information is provided. So the pictures just aren't sensible in that way

@JensHeinrich commented on GitHub (Jan 10, 2026): > Is the problem that you don’t want to leak the name of a person or that you don’t want to leak that two faces from two pictures are the same person? More the latter, especially if the normal face recognition would not be able to match them > Also the edge cases for sensitive images (I saw examples of trans that haven't come out and furries) seem like extreme edge cases where the simple solution is to just not share those sensitive images? The point is not the picture being sensitive, but the clustering of multiple faces being the problem. If you have a person with a full fur suit and without the fur suit you will probably not be able to guess they are the same person unless this meta information is provided. So the pictures just aren't sensible in that way

deekerman commented

2026-02-20 02:16:58 -05:00

Author

Owner

@D4ndellion commented on GitHub (Jan 10, 2026):

When software is used by hundreds of thousands of people, edge cases start looking a lot more like just, "cases"... It's important to think through these things and I find a lot of the comments here are frankly very dismissive in how they can't imagine how these social dynamics can be an issue. I agree that it would be nice to have some sort of simpler solution to fill the "shared account" usecase right now. But if we're discussing general solutions to sharing metadata for a final product, it's important to keep this stuff in mind.

It's not about individual sensitive images, but one can easily imagine people changing their names, from getting married, to being trans, or "random background strangers in school photos", or in the background of parties, stopping being random strangers. Without all these developments needing to be broadcast to everyone who has access to an image that doesn't even feature those people.

I don't have a great solution, but it really cant be as simple as attaching all metadata to the image equally in all sharing contexts, and it can't just be all or nothing. I don't think the userbase of the immich app are critical enough to properly evaluate how their choices in labeling facial recognition data and then sharing it will impact the privacy of the people in the images, it's not just about themselves, but potentially hundreds of people during certain events shared albums.

The risks need to be clearly communicated, and there should be tools to allow granular sharing so as to avoid people just "giving up" and sharing everything.

I'm not sure what it would look like, maybe you would have some context attached to the album with what faces should be shared through the album and with what names, and then they would just be able to be merged with the users normal face-collection with that alias as a hint. At least then it would be a conscious decision to share a link with specific faces. That way name-changes and new tagged people wont start showing up in historical albums without explicitly going into the albums and sharing it.

This could be done on any granularity one picks, account, album, image, or even per share link/person being shared to. Picking which ones strike the right balance for usability is more tricky, and why I selected album for the example.

I believe something like this is basically what @JensHeinrich is arguing for, that the metadata and images must be separated to allow such flexible sharing.

@D4ndellion commented on GitHub (Jan 10, 2026): When software is used by hundreds of thousands of people, edge cases start looking a lot more like just, "cases"... It's important to think through these things and I find a lot of the comments here are frankly very dismissive in how they can't imagine how these social dynamics can be an issue. I agree that it would be nice to have some sort of simpler solution to fill the "shared account" usecase right now. But if we're discussing general solutions to sharing metadata for a final product, it's important to keep this stuff in mind. It's not about individual sensitive images, but one can easily imagine people changing their names, from getting married, to being trans, or "random background strangers in school photos", or in the background of parties, stopping being random strangers. Without all these developments needing to be broadcast to everyone who has access to an image that doesn't even _feature_ those people. I don't have a great solution, but it really cant be as simple as attaching all metadata to the image equally in all sharing contexts, and it can't just be all or nothing. I don't think the userbase of the immich app are critical enough to properly evaluate how their choices in labeling facial recognition data and then sharing it will impact the privacy of the people in the images, it's not just about themselves, but potentially hundreds of people during certain events shared albums. The risks need to be clearly communicated, and there should be tools to allow granular sharing so as to avoid people just "giving up" and sharing everything. I'm not sure what it would look like, maybe you would have some context attached to the album with what faces should be shared through the album and with what names, and then they would just be able to be merged with the users normal face-collection with that alias as a hint. At least then it would be a conscious decision to share a link with specific faces. That way name-changes and new tagged people wont start showing up in historical albums without explicitly going into the albums and sharing it. This could be done on any granularity one picks, account, album, image, or even per share link/person being shared to. Picking which ones strike the right balance for usability is more tricky, and why I selected album for the example. I believe something like this is basically what @JensHeinrich is arguing for, that the metadata and images must be separated to allow such flexible sharing.

deekerman commented

Author

Owner

@kevincox commented on GitHub (Jan 10, 2026):

I think one relatively simple solution is that this "aggregate metadata" can be shared separately from images. Basically there is a "Face Clustering Realm" and "Face Label Realm". By default a user gets their own realms (like today). However all shared images are also processed in the receiver's realm and they can access that data. However users can choose to merge their realms together. If they share clustering information face identification improves and face merges are merged for both users. If they also merge labels then the face names are also shared. if you want to leave a Realm you would need to take a copy and evolve from there (or reprocess, but that is probably undesirable).

I think the realm concept makes sense, however I'm not sure how to present this to the user. Particularly just sharing the clustering data is very subtle. Maybe both are always just shared together? That would probably make it much easier for users to understand what is going on. But then you can't have different labels than a partner if you desire. Maybe there can be some sort of "default labels" that are in the realm but a user can override with user-specific labels?

So to wrap that thought up into a proposal it would be something like:

All photos a user has access to are processed inside a "faces realm".
By default users have separate realms, but they can join the realms of other users (with permission).
The default "label" behaviour would be to set the realm-wide label.
Users can also edit a "local" label for them only. (This may be prompted if editing an existing label.)

I think the main downside is that it is all-or-nothing and everyone in the group is equal. But I think that is probably fine. At least if you want you can process all images in your own realm, as opposed to today where you just don't have any faces or search for shared images.

@kevincox commented on GitHub (Jan 10, 2026): I think one relatively simple solution is that this "aggregate metadata" can be shared separately from images. Basically there is a "Face Clustering Realm" and "Face Label Realm". By default a user gets their own realms (like today). However all shared images are also processed in the receiver's realm and they can access that data. However users can choose to merge their realms together. If they share clustering information face identification improves and face merges are merged for both users. If they also merge labels then the face names are also shared. if you want to leave a Realm you would need to take a copy and evolve from there (or reprocess, but that is probably undesirable). I think the realm concept makes sense, however I'm not sure how to present this to the user. Particularly just sharing the clustering data is very subtle. Maybe both are always just shared together? That would probably make it much easier for users to understand what is going on. But then you can't have different labels than a partner if you desire. Maybe there can be some sort of "default labels" that are in the realm but a user can override with user-specific labels? So to wrap that thought up into a proposal it would be something like: 1. All photos a user has access to are processed inside a "faces realm". 2. By default users have separate realms, but they can join the realms of other users (with permission). 3. The default "label" behaviour would be to set the realm-wide label. 4. Users can also edit a "local" label for them only. (This may be prompted if editing an existing label.) I think the main downside is that it is all-or-nothing and everyone in the group is equal. But I think that is probably fine. At least if you want you can process all images in your own realm, as opposed to today where you just don't have any faces or search for shared images.

deekerman commented

2026-02-20 02:16:58 -05:00

Author

Owner

@drLaba commented on GitHub (Jan 15, 2026):

Resharing seems not to have been mentioned* before.

Use case:

user A attended an event, took pictures and stored them in an Immich album
- the album contains all the photos from the event, including the behind the scenes ones
user A shares the album with user B
user B would like to share a selected few photos from the album with guest C (who is a journalist covering the event)

Currently:

user B has no choice but to download the selected photos and either:
- upload them to their Immich account to create a share — duplicating the files on the Immich server
- send file copies directly to guest C (via e-mail, IM, etc.)
trying to share selected photos from a shared album results in an error message of:
```
Not found or no asset.share access (Immich Server Error)
```
- user B has Editor role assigned by the album owner user A
- I suspect this error is not a bug, but a not yet implemented feature*

Permission handling — in case user A ever decided to revoke user B access to the album, then the links user B had created and sent to guest C would simply become invalid (without the need to inform user B).

As an added bonus, the feature would not only enhance usability, but possibly also increase Immich awareness (when the guest C gets the link to an Immich instance and not simply the file copies).

*GitHub search lists only this issue, and text search within in for "reshar" doesn't find any matches

@drLaba commented on GitHub (Jan 15, 2026): **Resharing** seems not to have been mentioned\* before. Use case: 1. _user A_ attended an event, took pictures and stored them in an Immich album - the album contains all the photos from the event, including the behind the scenes ones 2. _user A_ shares the album with _user B_ 3. _user B_ would like to **share a selected few photos from the album** with _guest C_ (who is a journalist covering the event) Currently: - _user B_ has no choice but to download the selected photos and either: - upload them to their Immich account to create a share — duplicating the files on the Immich server - send file copies directly to _guest C_ (via e-mail, IM, etc.) - trying to share selected photos from a shared album results in an error message of: ```text Not found or no asset.share access (Immich Server Error) ``` - _user B_ has `Editor` role assigned by the album owner _user A_ - <img width="1105" height="945" alt="Image" src="https://github.com/user-attachments/assets/87d1053d-4849-4bb9-a523-24e7fa4767c6" /> - I suspect this error is not a bug, but a not yet implemented feature* Permission handling — in case _user A_ ever decided to revoke _user B_ access to the album, then the links _user B_ had created and sent to _guest C_ would simply become invalid (without the need to inform _user B_). As an added bonus, the feature would not only enhance usability, but possibly also increase Immich awareness (when the _guest C_ gets the link to an Immich instance and not simply the file copies). \*GitHub search lists only this issue, and text search within in for "reshar" doesn't find any matches

deekerman commented

2026-02-20 02:16:58 -05:00

Author

Owner

@drLaba commented on GitHub (Jan 15, 2026):

Other, nice to have features, I have not found mentioned (but those I might have missed).

Allow guests to comment and like ("heart") photos
- many people have Google accounts
  - when accessing a share from a public link they can "join" the share, and then are allowed to comment and like
- most people don't have an Immich account on a particular Immich instance :)
  - guests can never react to shared photos
- I realize it might be a stretch for Immich but:
  - this is a real drawback for younger family members who used to share their photos (via link) on Google Photos
  - although it falls within the scope of social media, I suspect Immich users could appreciate it if this Immich feature took one incentive to use social media away from their children (Google Photos did)
- proposed implementation:
  - enable and store reactions on a per share basis
    - no comment moderation tools would be needed then (i.e. in case unwanted reactions should be removed, just remove the share)
    - different (share) groups would have separate reactions (i.e. share for family members and shared link for friends)
  - have an input text field for "name" of the comment author
    - I believe it is safe enough to assume that if a person (guest) has the link (and password if needed), then he should be authorized to leave comments for that share
See shared photos in timeline
- if user A shared photos (say, an album) with user B, user B would see the photos on his timeline alongside his own photos
- per-user general setting to include or exclude shares in timeline
- per-share setting (set by the sharee) that overwrites the general setting

@drLaba commented on GitHub (Jan 15, 2026): Other, nice to have features, I have not found mentioned (but those I might have missed). 1. Allow guests to comment and like ("heart") photos - many people have Google accounts - when accessing a share from a public link they can "join" the share, and then are allowed to comment and like - most people don't have an Immich account on a particular Immich instance :) - guests can never react to shared photos - I realize it might be a stretch for Immich but: - this is a real drawback for younger family members who used to share their photos (via link) on Google Photos - although it falls within the scope of social media, I suspect Immich users could appreciate it if this Immich feature took one incentive to use social media away from their children (Google Photos did) - proposed implementation: - enable and store reactions on a per share basis - no comment moderation tools would be needed then (i.e. in case unwanted reactions should be removed, just remove the share) - different (share) groups would have separate reactions (i.e. share for family members and shared link for friends) - have an input text field for "name" of the comment author - I believe it is safe enough to assume that if a person (guest) has the link (and password if needed), then he should be authorized to leave comments for that share 2. See shared photos in timeline - if _user A_ shared photos (say, an album) with _user B_, _user B_ would see the photos on his timeline alongside his own photos - per-user general setting to include or exclude shares in timeline - per-share setting (set by the sharee) that overwrites the general setting

deekerman commented

2026-02-20 02:16:59 -05:00

Author

Owner

@m3e-g commented on GitHub (Jan 15, 2026):

I'd like to add my 2 cents on the sharing feature regarding the shared photos and timeline.
I don't think shared images should be automatically added to the own photos. This could do lead to potentially malicious use cases.

Alternatively something similar to Google Photos approach would be better. Shared albums are visible in the shared space and user can freely browse them, but to actually add the photos to his own timeline, user has to explicitly "add to library" (all images or just a subset)
I think this idea was tracked in the https://github.com/immich-app/immich/discussions/1587 and it should be included in the refactoring of the ownership.

This way own timeline is not polluted by other users, but still keeps the ability to include shared photos in the timeline when desired.

Another thought is that whenever user adds a photo to his own library, an asset should be reused until the moment one of the owners decide to edit the file. At this moment a new copy for the edited asset should be created, but any other owners should still have the old one. Again this would protect from impacting own library by another users.

@m3e-g commented on GitHub (Jan 15, 2026): I'd like to add my 2 cents on the sharing feature regarding the shared photos and timeline. I don't think shared images should be automatically added to the own photos. This could do lead to potentially malicious use cases. Alternatively something similar to Google Photos approach would be better. Shared albums are visible in the shared space and user can freely browse them, but to actually add the photos to his own timeline, user has to explicitly "add to library" (all images or just a subset) I think this idea was tracked in the https://github.com/immich-app/immich/discussions/1587 and it should be included in the refactoring of the ownership. This way own timeline is not polluted by other users, but still keeps the ability to include shared photos in the timeline when desired. Another thought is that whenever user adds a photo to his own library, an asset should be reused until the moment one of the owners decide to edit the file. At this moment a new copy for the edited asset should be created, but any other owners should still have the old one. Again this would protect from impacting own library by another users.

deekerman commented

2026-02-20 02:16:59 -05:00

Author

Owner

@drLaba commented on GitHub (Jan 15, 2026):

Thank you @m3e-g for picking up the subject.

I don't think shared images should be automatically added to the own photos.

I certainly don't either. The feature proposed should obviously be an opt-in (as I wrote).

user has to explicitly "add to library" (all images or just a subset)

You and I would have, but many users wouldn't take the time. At the same time, they still would appreciate "just having the photos", without having to look for them anywhere. I know my instance users surely would. Big tech made people lazy, and many would rather scroll a long way than navigate to an album, or "shared with me" tab. Also, for explicitly adding the shared images to their library, the users still have to locate them first.

I think this idea was tracked in the #1587 and it should be included in the refactoring of the ownership.

Thank you for linking this issue, I haven't seen it — though mostly because it is a separate issue:

#1587 is a library management feature (i.e. copying files without manually downloading and uploading). This comment would be closest to what I proposed.
my proposal is a view mode feature (and somewhat of an opposite — a means of avoiding the storage of file copies by different users). Also possibly, much simpler to implement.

Another thought is that whenever user adds a photo to his own library, an asset should be reused until the moment one of the owners decide to edit the file. At this moment a new copy for the edited asset should be created, but any other owners should still have the old one. Again this would protect from impacting own library by another users.

Here, I don't think this should ever be automatically enabled. Implicit copies creation would clutter the server. If the user (sharee) wants to make sure the shared asset remains (and without any edits) he should explicitly create himself a copy (manually or via some automated à la #1587 method). Though, if the instance maintainer is OK with it, automatic copy creation surely could be an opt-in administration setting.

@drLaba commented on GitHub (Jan 15, 2026): Thank you @m3e-g for picking up the subject. > I don't think shared images should be automatically added to the own photos. I certainly don't either. The [feature proposed](https://github.com/immich-app/immich/issues/12614#issuecomment-3753862707) should obviously be an opt-in (as I wrote). > user has to explicitly "add to library" (all images or just a subset) You and I would have, but many users wouldn't take the time. At the same time, they still would appreciate "just having the photos", without having to look for them anywhere. I know my instance users surely would. Big tech made people lazy, and many would rather scroll a long way than navigate to an album, or "shared with me" tab. Also, for explicitly adding the shared images to their library, the users still have to locate them first. > I think this idea was tracked in the [#1587](https://github.com/immich-app/immich/discussions/1587) and it should be included in the refactoring of the ownership. Thank you for linking this issue, I haven't seen it — though mostly because it is a separate issue: - [#1587](https://github.com/immich-app/immich/discussions/1587) is a **library management feature** (i.e. copying files without manually downloading and uploading). [This comment](https://github.com/immich-app/immich/discussions/1587#discussioncomment-10864602) would be closest to what I proposed. - [my proposal](https://github.com/immich-app/immich/issues/12614#issuecomment-3753862707) is a **view mode feature** (and somewhat of an opposite — a means of avoiding the storage of file copies by different users). Also possibly, much simpler to implement. > Another thought is that whenever user adds a photo to his own library, an asset should be reused until the moment one of the owners decide to edit the file. At this moment a new copy for the edited asset should be created, but any other owners should still have the old one. Again this would protect from impacting own library by another users. Here, I don't think this should ever be automatically enabled. Implicit copies creation would clutter the server. If the user (sharee) wants to make sure the shared asset remains (and without any edits) he should explicitly create himself a copy (manually or via some automated à la [#1587](https://github.com/immich-app/immich/discussions/1587) method). Though, if the instance maintainer is OK with it, automatic copy creation surely could be an opt-in administration setting.

deekerman commented

2026-02-20 02:17:00 -05:00

Author

Owner

@jonathan1107 commented on GitHub (Jan 16, 2026):

Throwing my vote in for this one. I was about to submit a feature request specifically targeting the ability to share facial recognition people with partners. I'd prefer my people-based searching to include results from all shared libraries and partner uploads that I have access to.

YES PLEASE !!!!!

@jonathan1107 commented on GitHub (Jan 16, 2026): > Throwing my vote in for this one. I was about to submit a feature request specifically targeting the ability to share facial recognition people with partners. I'd prefer my people-based searching to include results from all shared libraries and partner uploads that I have access to. YES PLEASE !!!!!

deekerman commented

2026-02-20 02:17:00 -05:00

Author

Owner

@MDrollette commented on GitHub (Jan 16, 2026):

The only remaining feature gap preventing me from migrating from Synology Photos to Immich is the "Shared Space" functionality (aka. full partner sharing). My wife and I simply want everything to be shared completely jointly between us. I assumed this was the intent with the partner sharing - a minimal way to share everything without the complexity of granular permissions - and the current implementation is so close. If that carried over to facial recognition and metadata then it would absolutely work for me.

Maybe there's some inspiration to take from the "Shared Space" in Synology Photos? Rather than trying to solve all these use-cases as a granular permission problem we can add a new higher-level concept in the way they use "spaces".

@MDrollette commented on GitHub (Jan 16, 2026): The only remaining feature gap preventing me from migrating from Synology Photos to Immich is the "Shared Space" functionality (aka. full partner sharing). My wife and I simply want everything to be shared completely jointly between us. I assumed this was the intent with the partner sharing - a minimal way to share everything without the complexity of granular permissions - and the current implementation is so close. If that carried over to facial recognition and metadata then it would absolutely work for me. Maybe there's some inspiration to take from the "Shared Space" in Synology Photos? Rather than trying to solve all these use-cases as a granular permission problem we can add a new higher-level concept in the way they use "spaces".

deekerman commented

2026-02-20 02:17:00 -05:00

Author

Owner

@photoserver-pro commented on GitHub (Jan 16, 2026):

100% agree — sharing is fundamental.

In my experience (Piwigo for years, plus QNAP QuMagie and TerraMaster), multi-user access and permission management are core capabilities. Every other solution I’ve used has a clear concept of how multiple users (family/friends) can be integrated with the right access controls.

Without robust sharing and permissions — i.e., the ability for others to access and work with my library in a controlled way — migrating to Immich doesn’t really make sense for my use case. For my personal “access on all devices” workflow, Lightroom Cloud already solves that.

A photo platform becomes truly valuable when it enables meaningful collaboration and viewing for other users (family/friends) — not just the owner.

@photoserver-pro commented on GitHub (Jan 16, 2026): 100% agree — sharing is fundamental. In my experience (Piwigo for years, plus QNAP QuMagie and TerraMaster), multi-user access and permission management are core capabilities. Every other solution I’ve used has a clear concept of how multiple users (family/friends) can be integrated with the right access controls. Without robust sharing and permissions — i.e., the ability for others to access and work with my library in a controlled way — migrating to Immich doesn’t really make sense for my use case. For my personal “access on all devices” workflow, Lightroom Cloud already solves that. A photo platform becomes truly valuable when it enables meaningful collaboration and viewing for other users (family/friends) — not just the owner.

deekerman commented

Author

Owner

@zacharyficker commented on GitHub (Jan 29, 2026):

One addition I think would be great is, for photos that are shared with you in an album, an option to have them show in your own library as well. Exactly like you can with the partner sharing feature, but just for a specific album.
Edit: like #1587

@zacharyficker commented on GitHub (Jan 29, 2026): One addition I think would be great is, for photos that are shared with you in an album, an option to have them show in your own library as well. Exactly like you can with the partner sharing feature, but just for a specific album. Edit: like #1587

deekerman commented

Author

Owner

@WoSan7000 commented on GitHub (Feb 1, 2026):

The current sharing options are too limited for 'proper' collaboration purposes, true. However, I think Immich never was intended for home/family/collaboration use. I (as most other people here) would really like to use it for just that collaboration scenario. At the moment the partner sharing feels incomplete due to no sharing of metadata and the fact that you have to explicitly flip a toggle for your partner pictures to show up in your timeline. If you partner share, that should be the default (imho) as you have no secrets of each other anyway 😉

Furthermore I'd like to say that I immensely like the Immich UX and already bought a server license to support you guys. It's just enjoyable to use and (imho) way better than the likes of Adobe Bridge, IMatch, etc. It's an app where non-techy users can also easily find their way around in and are not intimidated by the UX. Even older folks (70+) where I have shown this app have no issues to find stuff, which is a big thumbs up to the UX/frontend devs (thank you!). This makes Immich so special as it can be used in ALL environments (companies, clubs, private individuals, etc.).

As is repeatedly posted, I also largely like the idea of a sort of 'shared space' idea (collaboration model). In my view it would look something like this as I think this would be the most used situation for collaborating/sharing within a family (or even company):

Everybody who is a member of the created shared space also gets to be either a co-owner of it (thus everybody a collaborator with equal rights) or a viewer (view/search/download everything in the space, but can't do anything else). So, every member that is within 'the space' either has full control over it or can only view everything and alter nothing (all or nothing architecture). This would cut down on some permissions spaghetti I think and keep it maintainable. If you link media from your own account (a picture or video) to said 'space' then ALL the metadata is added in the space as well. Everything could be either a one-time copy OR a dynamic link. I think a copy (even if only for the metadata) would be better(?) as the default option. That way you don't get a metadata 'backfire' into your own private environment from where you added the pictures to the 'space' to begin with. I think this has potential and keeps everything more separated within all layers of the app at the same time.

Another supplemental idea (don't know the feasibility or whether it's a good idea at all) could be to have two modes in the Apps and Web UI. This could cut down work on the necessary adjustments within all separate (or extra to build) components as a lot could be reused with just another pointer to a space instead of an (personal) account. Anyway, the idea is to have one private mode and one collaboration/shared mode. You just flip a toggle that is discretely present in the UI (or make it a selection dropdown as you can be a collaborator on multiple spaces anyways) and everything is hidden, except the space you're working in at that time. This way you can fully focus on collaborating on the space/environment you selected while keeping permissions and other things under control. Every picture you upload at that time will automatically end up in the selected space/environment as well.

Maybe I haven't described it very clearly, but if anybody wants to know more about this idea, simply ping me and I'll try to explain more and happy to answer any questions 😄 Again, I really like this app and already use it for personal storage. If a collaboration mode would become available then it just blows all other options out of the water (again imho) as it could then also be used within (small/medium) companies 😀

Bonus 😆: To explain the company story a bit: A lot of small to medium media (and broadcasting/news) companies are contracted with one or a couple photographers (or have them in-house). The photos they produce are used within the organization for multiple departments. In the company where I work this would be the following departments:

HR or personnel management (mainly uses headshots).
Graphics (use photos as a source for creating derivative works of it that is also used, in part, by other departments).
Marketing (uses a lot from the Graphics department and uses photos from events where they were etc. in their expressions towards the public).
Editors (uses pictures they made themselves and by the photographers to give meaning to an article they wrote).

Yes, for the above are already (expensive) solutions available. In addition to that, most are clunky/hard to use for non-tech folk and/or unsuitable/prohibitive for the smaller/medium companies. I see a 'shared space' or 'multiple environment' feature as the best way to go forward for keeping the most users, by far, happy. Thereby it could also open up a whole lot of other situations where it could be used (like my company example above) where super fine-grained permissions are unnecessary. We've got other clunky systems that implement that fine-grained permissions part already, so why bother to do it again and get yourselves into a heap of development troubles. With a shared space and all-or-nothing permissions (or maybe add a 'view and add/upload only' role if not too complicated) we would get where most users want to be, I think.

Really hope something like this becomes available (can hardly wait!). Whatever the choice, keep up the good work! 👍

@WoSan7000 commented on GitHub (Feb 1, 2026): The current sharing options are too limited for 'proper' collaboration purposes, true. However, I think Immich never was intended for home/family/collaboration use. I (as most other people here) would really like to use it for just that collaboration scenario. At the moment the partner sharing feels incomplete due to no sharing of metadata and the fact that you have to explicitly flip a toggle for your partner pictures to show up in your timeline. If you partner share, that should be the default (imho) as you have no secrets of each other anyway 😉 Furthermore I'd like to say that I immensely like the Immich UX and already bought a server license to support you guys. It's just enjoyable to use and (imho) way better than the likes of Adobe Bridge, IMatch, etc. It's an app where non-techy users can also easily find their way around in and are not intimidated by the UX. Even older folks (70+) where I have shown this app have no issues to find stuff, which is a big thumbs up to the UX/frontend devs (thank you!). This makes Immich so special as it can be used in ALL environments (companies, clubs, private individuals, etc.). As is repeatedly posted, I also largely like the idea of a sort of 'shared space' idea (collaboration model). In my view it would look something like this as I think this would be the most used situation for collaborating/sharing within a family (or even company): Everybody who is a member of the created shared space also gets to be either a co-owner of it (thus everybody a collaborator with equal rights) or a viewer (view/search/download everything in the space, but can't do anything else). So, every member that is within 'the space' either has full control over it or can only view everything and alter nothing (all or nothing architecture). This would cut down on some permissions spaghetti I think and keep it maintainable. If you link media from your own account (a picture or video) to said 'space' then ALL the metadata is added in the space as well. Everything could be either a one-time copy OR a dynamic link. I think a copy (even if only for the metadata) would be better(?) as the default option. That way you don't get a metadata 'backfire' into your own private environment from where you added the pictures to the 'space' to begin with. I think this has potential and keeps everything more separated within all layers of the app at the same time. Another supplemental idea (don't know the feasibility or whether it's a good idea at all) could be to have two modes in the Apps and Web UI. This could cut down work on the necessary adjustments within all separate (or extra to build) components as a lot could be reused with just another pointer to a space instead of an (personal) account. Anyway, the idea is to have one private mode and one collaboration/shared mode. You just flip a toggle that is discretely present in the UI (or make it a selection dropdown as you can be a collaborator on multiple spaces anyways) and everything is hidden, except the space you're working in at that time. This way you can fully focus on collaborating on the space/environment you selected while keeping permissions and other things under control. Every picture you upload at that time will automatically end up in the selected space/environment as well. Maybe I haven't described it very clearly, but if anybody wants to know more about this idea, simply ping me and I'll try to explain more and happy to answer any questions 😄 Again, I really like this app and already use it for personal storage. If a collaboration mode would become available then it just blows all other options out of the water (again imho) as it could then also be used within (small/medium) companies 😀 Bonus 😆: To explain the company story a bit: A lot of small to medium media (and broadcasting/news) companies are contracted with one or a couple photographers (or have them in-house). The photos they produce are used within the organization for multiple departments. In the company where I work this would be the following departments: - HR or personnel management (mainly uses headshots). - Graphics (use photos as a source for creating derivative works of it that is also used, in part, by other departments). - Marketing (uses a lot from the Graphics department and uses photos from events where they were etc. in their expressions towards the public). - Editors (uses pictures they made themselves and by the photographers to give meaning to an article they wrote). Yes, for the above are already (expensive) solutions available. In addition to that, most are clunky/hard to use for non-tech folk and/or unsuitable/prohibitive for the smaller/medium companies. I see a 'shared space' or 'multiple environment' feature as the best way to go forward for keeping the most users, by far, happy. Thereby it could also open up a whole lot of other situations where it could be used (like my company example above) where super fine-grained permissions are unnecessary. We've got other clunky systems that implement that fine-grained permissions part already, so why bother to do it again and get yourselves into a heap of development troubles. With a shared space and all-or-nothing permissions (or maybe add a 'view and add/upload only' role if not too complicated) we would get where most users want to be, I think. Really hope something like this becomes available (can hardly wait!). Whatever the choice, keep up the good work! 👍

deekerman commented

Author

Owner

@cchristchurch commented on GitHub (Feb 1, 2026):

Out of all the coming-soon features listed on the roadmap, for me this is by far the most important one 😍

I'm not seeing it explicitly mentioned here, but the ability to "favorite" a picture shared in an album by another user, and have the picture appear in my favorites, is a big one for me. A possible workaround would be to be able to add a shared picture to my own "my hacky favorites" album, but as mentioned above this is not possible either at the moment.

In terms of implementation, I'm wondering if the idea of "ownership sharing" could make sense: for instance I can select pictures from a shared album and have them copied to my own timeline. This would have the same effect as downloading / re-uploading the picture, but ideally without creating a duplicate file in immich: the server could track who owns a file and only delete it once all users have deleted it.

This could be a rudimentary way to solve face recognition/metadata sharing: all these features could be made to work as they do now based on the photos in my timeline. Of course this means that we are not sharing people names for instance, and all users need to put their own names on faces. I don't mind that but I guess others may disagree.

Without the concept of ownership sharing, if I favorite a picture from another user and that user deletes it I guess the only sensible behavior would be for that picture to disappear for me too. This is a bit less than ideal, but still acceptable. Maybe I could get a notification in that case?

@cchristchurch commented on GitHub (Feb 1, 2026): Out of all the coming-soon features listed on the [roadmap](https://immich.app/roadmap), for me this is by far the most important one 😍 I'm not seeing it explicitly mentioned here, but the ability to "favorite" a picture shared in an album by another user, and have the picture appear in my favorites, is a big one for me. A possible workaround would be to be able to add a shared picture to my own "my hacky favorites" album, but as mentioned above this is not possible either at the moment. In terms of implementation, I'm wondering if the idea of "ownership sharing" could make sense: for instance I can select pictures from a shared album and have them copied to my own timeline. This would have the same effect as downloading / re-uploading the picture, but ideally without creating a duplicate file in immich: the server could track who owns a file and only delete it once all users have deleted it. This could be a rudimentary way to solve face recognition/metadata sharing: all these features could be made to work as they do now based on the photos in my timeline. Of course this means that we are not sharing people names for instance, and all users need to put their own names on faces. I don't mind that but I guess others may disagree. Without the concept of ownership sharing, if I favorite a picture from another user and that user deletes it I guess the only sensible behavior would be for that picture to disappear for me too. This is a bit less than ideal, but still acceptable. Maybe I could get a notification in that case?

deekerman commented

Author

Owner

@isZYKerman commented on GitHub (Feb 8, 2026):

Will this support server federation? My friend and I each host our own Immich instances, and we’d love to have collaborative albums that work across servers. It would be amazing to pool our photos into one shared album whenever we go on vacation together.

@isZYKerman commented on GitHub (Feb 8, 2026): Will this support server federation? My friend and I each host our own Immich instances, and we’d love to have collaborative albums that work across servers. It would be amazing to pool our photos into one shared album whenever we go on vacation together.

deekerman commented