[Feature]: Externally shared album to non-users (collaborative / non-collaborative)

[hugo-laestander]

Feature detail

Often when a group of friends has done something together, they will have taken photos that the other people in the group would like to have. People want a quick and easy way to share the photos (without destroying the quality).

I think this would be a great feature for Immich to have, and as I see it, two options could be had:

1. a combined shared album where everyone can contribute (collaborative),
2. an album for only viewing and download (non-collaborative)

This might be the only shared album they will ever have access to. And neither me nor they want to make an account.

Therefore, I think it would be very good if they did not have to make accounts. The shared album could be done with a link and optionally a password.

Platform

Web

[alextran1502]

I think the album feature on the mobile app is serving what you are looking for, correct?

If so, it is just not being implemented on the web yet but the plan is in place.

[alextran1502]

Ah I apologize, I misread the title. This is to share the album externally.

[bo0tzz]

On this feature, it might be nice if sharing links could be set to expire after a certain time, and to have a button to expire/revoke them manually.

[danielyrovas]

Also would love this feature. One less thing to use slow and clunky Nextcloud for.

[axgd-code]

This could be a killer feature!

[matthinc]

I really like the idea. We just briefly discussed this topic and decided to start by collecting requirements that will help us to choose an appropriate architecture as this feature will require major changes to Immich. Please feel free to share your ideas as well, I will add them to the list.

• As a logged in user, I want to share albums with users that don't have their own account.
• As a logged in user, I want to set an expiration date to publicly shared albums
• As the owner of a shared album, I want to add password protection to publicly shared albums to protect them from unintended access
• As an external user viewing a publicly shared album, I want to upload my own assets to the album
• As the owner of a shared album I want to revoke public access from shared albums
• As an external user, I want to download assets from shared albums
• As a logged in user, I want to track activity on my shared albums
• As the owner of a shared album, I want to create multiple sharing links with different expiration dates
• As the owner of a shared album, I want to review assets that were uploaded by external users before they appear publicly
• As the owner of a shared album, I want to control the permissions of external users on this album (uploading, viewing, deleting)
• As an external user, I want to be able to view a shared album on my mobile devices (responsive design)

As a first source of inspiration, I added a screenshot below that shows the sharing menu of a Nextcloud instance. I think they executed it rather well.

[axgd-code]

Another way to allow people to add some pictures is a public page just for the upload. I prefer the implementation of Nextcloud because you specify the sharing in the album but I think that Synology's way is easier to manage : you have a datagrid of all "sharing links".

[puregreen59]

agreed! would Love this

[jrasm91]

I'll just add that the google photos sharing solution works well for me, and doesn't seem overly complicated.

1. Share urls are long random strings, and don't require passwords. I'm not sure exactly what pros/cons there are to this vs passwords, but it is easier to share IMO.

2. Users can view without an account, but adding assets requires logging in.

I'm on board for multiple, expirable links too though.

[bmachek]

+1

[Cat-Ion]

If possible, I would also love to have public shares of singular images, without having to create an album first. Should I create a separate issue for that?

[Mortein]

Can there be a separate password/secret from the album/asset being shared? The secret doesn't need to be customisable, just something random that isn't easily brute forceable which isn't related to the album.

Using just an identifier as a public share link is security through obscurity, and it scares me. Google does it wrong for both YouTube (unlisted videos) and Google Photos (share with link). The UUID RFC recommends against it, too.

Something like: /share/[asset-id]/[secret]

Only when both the asset identifier (photo/video/album/whatever) and secret are correct should the user gain access, in all other cases they should be told something generic (otherwise they know the ID is in use).

[jrasm91]

Alex has started working on this and we aren't using a uuid in the url but randomly generated bytes using node's crypto library.

The url looks like this: /share/[secret]. If the secret is secure (not guessable through brute force) then we should be good from a security perspective.

The secret only grants access to a specific list of assets or album.