A few thoughts:

1. Let's say files inside tags use the collection key of the parent album. Access to a tag (e.g. if I shared it with someone) therefore requires access to the collection key, thereby potentially exposing the entire album. (E.g. if a government agency got hold of a public link I've shared to a single tag inside a bigger album.) Bad.

2. Alternatively, let's say all file keys of files belonging to a tag will also be encrypted with an additional tag key (separately from the encryption with the collection key). This is certainly doable and I assume you already do a similar thing for photos belonging to multiple albums/collections. However, with nested tags this might get annoying fast if a file key needs to be encrypted not only with the tag key of the tag "foo/bar/baz" but also with the tag keys of "foo/bar" and "foo". If you wanted to avoid this, you'd encrypt the tag key of "foo/bar/baz" with the tag key of "foo/bar" and the latter with the tag key of "foo". But then isn't this more or less exactly what you would do if you implemented nested collections?

On top of this, you will need to store an encrypted map of tag -> tagged files somewhere both for performance reasons, for privacy reasons (if you stored the tags inside the files, you'd risk exposing them to people the tags weren't shared with), and to manage write access (contributions) to a tag.

All this, I assume, is also what you do for collections. So then, all in all, how different from collections would tags really be?

--

Irrespective of the encryption questions, wouldn't the addition of tags complicate your domain model quite a bit? You'd likely also need new API endpoints, and separate UIs for viewing photos belonging to a tag (as opposed to an album), sharing a tag, editing/renaming tags, …