Smart albums are collections that support rule based additions, as well as one-off additions. So a contributor can add photos directly to the collection, without the owner's clients not having to perform any extra computation. Also, for one-off additions, tags are irrelevant (the metadata of added items will stay unmodified).
Smart albums will show up next to regular albums, unless you hide / archive them. So you will unfortunately end up with multiple albums next to each other. For the workflow you've mentioned, we have plans to make albums where collaborators can only view the items they have added - so you could share "2026 Summer vacation" to collect photos from Bob and Alice, and you will be able to see photos added by everyone, while Bob and Alice will only be able to see theirs.
Current plan is to keep tags as part of an item's metadata, and allow sharing and access control with "smart albums" - that create a collection view over a tag-filter.
For eg. you can create a "smart album" for items that match the tags ["2020", "Holidays"]. Your devices will auto-add any items in your library that match these tags, to this collection. You can then share[0] this album with recipients who can view / add / auto-add items from their library.
The way I've thought about this, we will not have "files inside tags", but we will have tags (foo, bar, baz) attached to a file as additional encrypted metadata.
We have existing client-side infrastructure[0] that can create auto-updating albums based on metadata, and this can be extended to enable sharing workflows.
You will be able to create "smart albums" with nested tags, and share (and contribute) to them.
Albums are tag-like in the sense you described it, but might be an overkill[0] for the outcome we wish to achieve - organization, sharing, and ability to respect original folder structure when a user exports their data.
For a bootstrapped, engineering-driven company like Ente, product offers the best leverage for growth. We are not P0-ing nested folders right now because we believe there are areas within the photos app investing into which will provide higher revenue returns, that we can re-invest into increasing our engineering bandwidth.
Now I understand the disappointment around us not prioritizing a feature that is blocking you from even using the product. It is a loss for all parties, but it is important for us to plan long-term. And while we're not prioritizing this specific feature, I don't think it is fair to say that we do not invest time into polish. We do care about our craft[0][1][2].
We've been using Scaleway's compute, RDS and S3 offerings for Ente[1]'s cloud offering for over 5 years now.
RDS backups and retrivals from cold storage[2] are both a lot slower than AWS. The "high-availablity" instances for RDS are in the same DC, so the feature is cosmetic. Ignoring these, our experience has been pretty good. Quality of support is great.
--
While linking to [2] I realised that Scaleway's own website is behind Cloudflare, which is disappointing given they have their own DDoS protection[3].
Smart albums will show up next to regular albums, unless you hide / archive them. So you will unfortunately end up with multiple albums next to each other. For the workflow you've mentioned, we have plans to make albums where collaborators can only view the items they have added - so you could share "2026 Summer vacation" to collect photos from Bob and Alice, and you will be able to see photos added by everyone, while Bob and Alice will only be able to see theirs.