I've been a big fan of Ente and their work and am a paying customer but, man, this comment in a long-standing GitHub feature request is ringing truer every day:
> Ente is becoming like Proton: too many products and a lack of focus, leading to lower quality and not delivering what customers want
Hi Vishnu, thanks for engaging here – it is highly appreciated! Let me respond to a couple of your statements from the interview:
> I think it's important to offer a complete package
I agree. But doesn't that start with making one product (Ente Photos) good enough for people to actually be able to migrate? If Ente Photo really is your "home ground", as you say, shouldn't you prioritize accordingly? Specifically, in your response[0] to the GitHub issue I linked you say
> to pull it off with the finesse we would like, it will take us more than a quarter. […] I will mark this feature as unplanned until we have more engineering bandwidth.
But it seems you really do have the engineering bandwidth! You've just been prioritizing other products besides Ente Photos. I do understand that folder nesting in particular is a non-trivial change and if you look at the discussion on GitHub, I've actually been defending you rather heavily. But it's becoming increasingly difficult to do so – quite frankly, I am starting to doubt your product management is entirely on the right track if in 3 years you can't dedicate 3 months to the feature request with the highest number of votes by far. More generally, I am losing trust that any of your products will see enough polishing any time soon. (So I will definitely not put time into migrating anything else if I can't even migrate my photos yet.) And it seems I'm not the only one thinking that – your reputation among enthusiasts is starting to take a hit.
> There is no way Ente is going to let anyone else build a better photo app.
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].
Thanks again for the YouTube link – I hadn't had time to watch the entire video yet, so I wasn't aware your product lead addressed nested folders specifically.
So how would nested tags interact with albums? Will I also be able to share (or contribute to) tags like I can share (or contribute to) albums? Actually, aren't albums already "tag-like" in the sense that photos can be assigned to multiple albums at the same time?
> 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].
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.
So if I understand you correctly, users will be able to share tags from a given album but you don't want to make tags separate collections (inside the existing album collection). But what is the alternative here if you want to secure access to the tags cryptographically (which I hope you do)?
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, …
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.
I'm not sure I understand yet. If tags (and the photos associated to them) are supposed to be shareable with others, how do you control read/write access to the tag if you don't use separate cryptographic keys? If you re-use/share existing keys (e.g. the parent album's collection keys), how do you ensure the recipients cannot read other photos or tag metadata not shared with them? What am I missing?
Once again thank you for taking the time to discuss this here! I appreciate it!
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.
> You can then share[0] this album with recipients who can view / add / auto-add items from their library.
IIUC, when a contributor uploads a photo, the owner of the smart album would need to do some client-side synchronization and 1) add the uploaded photo back to the original album and 2) add the tags ["2020", "Holidays"], so as to control write access to the original album & tag?
Either way, would these smart albums show up next to regular albums, though, or be "hidden"? I'm asking because what I would like to do, e.g., is to have a photo album for all our summer vacation photos and then create a subfolder (tag) for each family member to upload their photos in. If the smart albums all showed up in the top-level (flat) album list, I'd end up with a bunch of albums "2026 Summer vacation", "2026 Summer vacation - Alice's photos", "2026 Summer vacation - Bob's photos" all next to each other, which would kind of defeat the purpose in many ways.
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.
> 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.
What I meant was that if the smart album's purpose is allowing contributions to a tag in some other album, then contributed photos will have to be tagged & added to the original album by the owner, won't they, since only the owner holds the collection key.
> For the workflow you've mentioned, we have plans to make albums where collaborators can only view the items they have added
I'm not sure this would cover my use case. 1) I don't like other people's photos getting mixed up with mine for various reasons, which is why I typically set up one subfolder (or in Ente: a separate album) per contributor. 2) I want different people to have write access to their corresponding subfolder, but they should have read access to a larger set of subfolders (e.g. each others' photos, or maybe even the entire "summer vacation" album, though not necessarily).
All in all, the mechanisms you propose seem rather complex to me (and still inferior) compared to simply allowing albums/collections to be nested. And when I say "complex" I mean this not just from a technical point of view, but also from a conceptual & UX one. In the interview on YouTube you mention that a folder hierarchy might seem foreign to younger users but even if I believe that, is the solution really to come up with a solution that's foreign to everyone?
Besides, the entire industry has settled on nested folders as the primary way to organize files & documents as well as access control, from traditional file systems over Dropbox, M365 / SharePoint / One Drive to Confluence. So I'd say whoever is unfamiliar with that will become familiar fast, don't you think?
> Ente is becoming like Proton: too many products and a lack of focus, leading to lower quality and not delivering what customers want
https://github.com/ente-io/ente/discussions/552#discussionco...