Add parsing of `sharedAlbumComments` when importing shared albums

[linuxturtle]

In Google Photos, shared albums have the ability to associate comments with the album and/or individual photos in the album. This is represented by an "Activity" log, and is exported in each album's metadata.json file as the sharedAlbumComments structure. Immich apparently has a very similar feature, represented by the Activities API. I would like to request that immich-go import these comments into the created shared albums. This looks like it could be easily done using the createActivity API.

Ugh, upon further investigation, it looks like only some random assortment of comments are in the metadata.json file, but not all of them. The rest of them apparently show up in the shared_album_comments.json file at the top of the takeout structure, and are only associated with a particular album via the contentUrl field. I don't see any logic or reason behind which comments show up where, except that there's no contentOwnerName field in the shared_album_comments.json file, so apparently all of those are comments by the album owner? There are also album owner comments in the metadata.json file, though, so it's not obvious what causes them to be in one or the other.

Hmm, looks like I did this wrong. I created this as a result of Discussion #433 when maybe I should have just converted it to an issue. Well, now they're linked I guess..

[linuxturtle]

OMG. It looks like the sharedAlbumComments struct can also be hiding inside individual asset/photo .json files too.

[simulot]

Don't forget that images and albums have only one field for the description.

[linuxturtle]

Yes, I understand, this is not a description. It's an "Activity" log associated with the shared album and/or photo. This doesn't exist for regular albums, only shared ones. It works the same way in Immich. If you create a shared album, a comment bubble appears at the bottom of the photos/album. I'm pretty sure this corresponds to the "Activities" API.

[simulot]

I don't know this exists...
We should not duplicates the messages when the photo / album has been already created during a previous import

[simulot]

By the way, thank you for your sponsorship! Really appreciated

[linuxturtle]

I have created a testing google photos album that I'd be happy to share (it's 11M), but I've been unable to get google to create the shared_album_comments.json file. The example I have of that file is from a much larger album, but I suppose I could sanitize the file and attach it here. Would either of those be helpful?

WRT sponsorship, I just want you to know I appreciate your work of making open such a useful tool! I don't think my attempting to code up a patch in go would be very helpful, since I've never written anything in it before :laughing:

[linuxturtle]

Oh geeze. So now I'm back to the shared_album_comments.json file being redundant. As far as I can tell, in the example album I have, all the comments in the shared_album_comments.json file are duplicated in each individual photo/asset .json file they're associated with. This makes sense, because the shared_album_comments.json file does not contain any information associating the comment with an asset/photo, yet all the comments in the file I have are associated with an individual photo. It only contains a timestamp and URL for the shared album.

So, to summarize what I looks like is going on: The metadata.json file for the album can contain a sharedAlbumComments struct, containing one or more comments, along with timestamps and owners. I don't see any other indication whether the album is shared or not. Along with this, individual photo/video .json files contain the exact same sharedAlbumComments struct, but those comments are associated with the individual photo in the album. Oh, and the comments only apply to the copy of the photo in the album, they are not associated with the photo itself outside of the album. So immich-go will have to look at the asset .json file, even if it's a duplicate of an asset in the main archive.

I've attached the takeout file for a test album I created. Hilariously, github would only accept it if I capitalized .TGZ in the filename. :rofl: Hopefully that won't cause a problem. The URL of the test album is https://photos.app.goo.gl/om8RbJ6P7h6AHGo6A

takeout-20240812T202617Z-001.TGZ

[simulot]

Thanks for your analysis. Google Photos is good enough to avoid suits. Don't expect it to be easy, optimized and exhaustive...

The Album folder contains anything we need:

• album level comments in the metadata.json file
• photo level comments in the JSON associated with the photo

The immich create API (https://main.preview.immich.app/docs/api/create-activity) shows following:

• Author of the comment isn't given. I propose to add its name to comment text
• The possibility to have likes.

I have liked the Billy Joe photo. Could you extract the album again?

[linuxturtle]

I have extracted the album again (this time as a .zip file). Thanks for doing the "like", I didn't think about that. Looks like doing so adds another optional liked field to the sharedAlbumComments struct. I like your idea of adding the owner name to the comment text, at least for now. Kind of strange that the immich API doesn't have an owner field for comments, as comments in the GUI are attributed to the correct owner. Maybe an oversight in the create-activity API.

takeout-20240814T150101Z-001.zip

[simulot]

Anyway, the user identity is valid only for Google Photos... The probability that the user doesn't exist in Immich is high. Immich uses certainly the identity behind the API key for the comments created via the API.

There is no notion of date of the comment. So all comments will be created at the date of the import.

Last point: reprocessing a takeout is a common practice... This is possible because immich-go can check if the photo is already uploaded, and which album it should belong to. It's not possible to make a difference between comments imported and comments added by the user using immich. So the usual trick that is delete everything and re-import isn't ideal.

Knowing this, I'm wondering if having this imperfect import is desirable.

[linuxturtle]

I agree 100% that it would be impossible to map google photos user onto immich user, even if the API allowed such a mapping, so just putting username into the comment is the best choice.

WRT the date, immich does keep track of comment dates, but again, the API has no facility for setting this, so using the date of the import is best.

WRT reprocessing the takeout, yes, I see your point. The API does have the facility to retrieve activities, so it may be possible to do this, then compare comments, similar to how photos are compared to not upload duplicates. But if that's impractical, maybe a command line flag making the comment import optional? That way it could be done only the first time? Personally, I would much rather have an imperfect import, than no import at all.

[simulot]

We can also motivate the immich team to add missing fields to their API:

• Comment date, optional, default to the current time
• Comment's user, optional, default to the current API key owner

Then the google date of the event can be a key field. It won't change over import tasks or even across several takeouts. The user identity remains an issue: how to map any random google photos users to an immich user.

[linuxturtle]

That would be wonderful if the immich team would add those fields, I have opened a feature request for such an addition. Even if they don't implement it though, an optional import with the dates wrong and the user name in the comments would be much better than not importing it at all :smile_cat:

[linuxturtle]

No reaction or comment on the immich feature request yet. Any chance of an optional comment import in the meantime?

[simulot]

The limitations of the current API limit the interest on this feature. The Immich roadmap announces some changes on the user rights. I'll try to contact the core team