Ente: Open-Source, E2E Encrypted, Google Photos Alternative
ente.io
ente.io
We had opensourced our server[1] yesterday, which is perhaps why we are on the front page. Stoked to be here
Ente had launched on HN[2] a while ago and has been sustainably growing since.
We took the feedback from our Show HN seriously and have since
- undergone a cryptography audit [3]
- published our replication strategy [4]
- added requested features (family plans, collaborative albums and links, ...) [5][6][7]
- made progress with Edge ML [8][9]
- built a CLI for incremental data exports (our desktop app supports this as well) [10]
- and in general matured as a company [11]
Also, apart from our source code, our Figma[12] is public as well.
If you've feedback on what we could do better, please do share, it'd be very helpful.
And if you've any questions, do ask, I'd love to make myself useful.
[1]: https://ente.io/blog/open-sourcing-our-server/
[2]: https://news.ycombinator.com/item?id=28347439
[3]: https://ente.io/blog/cryptography-audit/
[4]: https://ente.io/reliability
[5]: https://ente.io/blog/family-plans
[6]: https://ente.io/blog/collaborative-albums/
[7]: https://ente.io/blog/collect-photos/
[8]: https://ente.io/blog/image-search-with-clip-ggml/
[9]: https://ente.io/blog/desktop-ml-beta/
[10]: https://github.com/ente-io/cli
[11]: https://ente.io/blog/reflections-on-trusting-trust/
[12]: https://www.figma.com/file/SYtMyLBs5SAOkTbfMMzhqt/ente-Visua...
Do you backup changed photos in iOS?
How do you backup a slow motion video on iOS? Synology exports, meaning your 240fps video becomes a 30fps video.
Immich retains the 240fps.
Just tested out a slow-motion video on iOS, we unfortunately don't retain the transformation.
On the brighter side of things, it's just a transformation. We are retaining the original file as is. So will look into how Immich is handling this format. Thanks for bringing this up!
How it's played is not a concern of the backup tool. It is a concern of the player.
Synology exports. So I record something at 240fps, and then the file uploaded is 30fps. That's not a backup.
It's like when you backup a photoshop PSD. You want a backup of the PSD, not a flattened PNG.
```
Stream #0:0[0x1](und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, bt709), 1920x1080, 78644 kb/s, 239.70 fps, 240 tbr, 2400 tbn (default)
```
I think it would be cool for the player to recognize a 240fps video and allow it to play slow mo. But again, that's a client responsibly.
This stuck ut immediately to me trying the app out, which made me read about it on your blog[0]. Oddly, when accessing Ente on the web (Safari on a Mac), the thumbnails look right but the full view is sRGB.
I understand Flutter has made some progress in this department [1], but I guess there's more going on here?
The fundamentals of the project look absolutely great! Hope to become a user very soon.
[0]https://ente.io/blog/tech/display-p3/ [1]https://github.com/flutter/flutter/issues/55092#issuecomment...
Maybe we can give temporary access to processing steps in the pipeline, then have Immich forget the keys after it does the processing?
I've scribbled a bit about the story behind the name and the mascot here: https://ente.io/blog/ducky/
> Our open source code has been audited by reputed cryptographers.
I think you probably mean "reputable", as "reputed" inspires a lot less confidence.
Dictionary Definitions from Oxford Languages · reputed /rɪˈpjuːtɪd/ adjective past participle: reputed
2. widely known and well thought of. "a highly reputed company"
Similar:well thought of, well respected, respected, highly regarded
But like OP pointed out, "reputed" could also mean
> generally believed to exist or be something specified, but not definitely the case. "a reputed budget of $165 million"
For now I've replaced it with the less ambiguous word ("reputable") to remove any confusion and will pick a better way to phrase this the next time we iterate on the landing page.
But it splits your metadata (like capture time, geo coordinates) and places them in a separate sidecar file.
This isn't an issue if you're migrating to Ente because during import the desktop app[1] will merge the metadata with their respective files.
If it's for you to keep a local copy, you will unfortunately need to write some scripts. There's in fact a paid product[2] that does just this.
The latter is very likely in the long run.
There's this tool that can fix capture times: https://github.com/mattwilson1024/google-photos-exif
There are perhaps more that I'm unaware of.
However, your reply gives me pause. The website says the apps are open-source, the other comment says the server is now open-source. Does that mean there's some pluggable black-box magic that the subscription enables?
To ask another way, if I self-host the server, can't I build the desktop app, import from Google Photos and then somehow export from the self-hosted server? Maybe not as ideal as a purpose-built script? Or is this not even possible?
So there is no black-box magic that the subscription enables. Our live, breathing production setup is available in a monorepo here[1].
> is this not even possible
This is very much possible.
I've added an updated comment here[2], thanks!
Not very straight forward, but it should work :)
But with takeout the problem is that all dates and metadata gets messed up. I had to learn this the hard way. There is some tools that somehow correct the dates. But it's not perfect and I wouldn't really want my photos to be locked up like that. What if google decides to discontinue Google Takeout? Or just give you lower quality pictures after some point? You really are not safe.
Since that experience I moved to onedrive temporarily because it's a bit safer solution for now until all of these new services get stable (immich, ente, etc). Onedrive let's you access you photos like normal Onedrive files so that's really good. I know microsoft will have my data now and sync is also not perfect. So it's definitely not perfect. But I had to move to something else before the better solutions emerge.
Google Photos already has a public API. But you cannot consume it if you are building a competing service[1]. Also, the APIs will not serve you files in their original quality.
If they wanted to honor the intent behind GDPR's portability mandate, it would have been trivial for them to enable seamless migrations.
Now what's ironic is how Google is a "partner" in the Data Transfer Initiative[2].
[1]: https://developers.google.com/photos/library/guides/acceptab...
[2]: https://dtinit.org
OneDrive ceased to be a good backup alternative when they stripped GPS from all my photos 1-2 years ago. Unlike Google, there's no way to recover original files. They simply destroyed them.
This is scary. Isn't OneDrive supposed to keep files bit-identical? Or were you using their iOS/Android apps to back up photos, and some bug caused the photos to be backed up without their metadata?
Their mobile app is now stripping GPS on upload while files uploaded from desktop are unaffected.
However the files I already had uploaded going back to 2017 were stripped. No idea if this was done server side or by the mobile client but the end effect is the same.
Unlike Google, Microsoft doesn't bother documenting this policy.
Always good to see some one from this side making to the front page of HN!!
Please note that if you're primarily using SmugMug to store RAW files, their support (in terms of previewing capabilities) is limited right now. It's on our roadmap, and we will prioritize it, but just wanted to give you a heads up.
Flickr does it, why wouldn't SmugMug?
But, sending multiple emails to customers with a threat to delete their private photos unless they pay, is a kafkaesque way to do business. Sorry, I'm not going to pay for something when I'm treated with actual hostility...
April 19th 2022: [IMPORTANT] Free account limit enforcement changes.
May 12th 2022: FINAL NOTICE: You are in violation of our free account limits.
Oct 6th 2022: Reminder: Your account is in violation of our free account limits.
I think "actual hostility" would have been simply shutting Flickr off, something Yahoo was ready to do. (Post acquisition, they later publicly admitted they regretted not doing just that[1]). I'm surprised you view getting notices that you have the opportunity to download your content (or pay for it, your choice) to be hostile. Is it less hostile to simply delete the data with no warning, like hundreds of other services have done?
We've tried hard to thread the needle between fixing Flickr's business model (it was losing tens of millions of dollars a year when we bought them, primarily because giving away 1TB/account for free is not sustainable) and giving people plenty of time to download their photos prior to deletion.
Tough problem, tough situation, but I'm largely proud of how we've handled it - there's been plenty of runway and notice for people to get their photos back if they prefer not to pay (either scenario - paying or downloading - is fine in our minds, but losing photos is not). We're not holding them hostage or anything, we want everyone to have them, one way or the other.
Email open & click rates being what they are (low), we carefully tracked them, plus download and/or subscription rates, to determine how frequently to contact people so we could have a high confidence that most people knew they had a choice and had the chance to make it.
Your photos over the free limits will be deleted, eventually. I don't know when, for your specific account, but it's certainly not just to "silence empty threats". It's not a threat, it's a statement, and it was intended as a courtesy.
I'm glad you have a choice AND you _know_ you have a choice.
[1] https://www.wsj.com/articles/verizon-to-lay-off-7-of-media-g...
I think we have different perspectives on things. Flickr wasn't a way to archive content, it was a way to share it before social media showed up. The need for Flickr died over the years.
I don't really care if Flickr deletes the photos or not, they were all backed up when I originally uploaded them because I've been conditioned to services just deleting content on a whim. Those of us in crypto say, not your keys, not your coins. Similar mentality. I'm accustomed to hostility.
Sending a FINAL NOTICE and then a more friendly reminder, and then not doing anything, is hostile behavior intended to extort people to pay money for a service that really hasn't seen any improvement in a very long time.
My $0.02... listen to them and shut it down and stop burning money on it. But you won't do that cause 'the choice' must be profitable enough to keep it going.
I'd argue that we have the same perspective on things - Flickr is a way to share, not archive. (Archival may be a wonderful side benefit, but community and connection are what makes Flickr magical, archive is a bonus) Yahoo had a different perspective. We're attempting to reverse it.
And we're succeeding. Across every metric you can imagine, Flickr is the healthiest it's ever been. More active users, more engagement, more connections, more revenue, more of everything - except people treating it like a "photo dump".
Most importantly, our members are ecstatic about it, it's now profitable and cash flow positive, so not in imminent danger (and we're trying to build it, sustainably, for 100+ years[1]). IMHO, it's not nearly enough, yet, but the trajectory is awesome. It's working. And it's working without invading people's privacy, unlike nearly every other social media platform.
We haven't "not done anything". Your account, for reasons I don't know, though someone here at Flickr likely does, hasn't seen anything. There's a big difference. Other accounts have. Every account will, eventually, including yours. Sorry you got an extra runway. ;) We're trying to be VERY careful about deleting photos.
I'm glad you had (and have?) backups. We know definitely, though, that MOST of our members did not. You were an outlier, but our outreach to people without backups was very appreciated. They had a very clear choice, we didn't hold their photos hostage, and that mattered to them.
It was definitely not intended to extort anyone - the options were very clear: download your photos and/or pay for the storage. (I think "and" is the right choice, but I'm biased... I also don't keep my photo archive _only_ on SmugMug and/or Flickr). The vast majority downloaded, rather than paid, and we view that as a win.
We gave people years to learn, choose, and act. I'd say that's pretty generous, and more generous than nearly any other troubled Internet service I've ever heard of. Are you aware of one that's been more generous? If you DIDN'T have backups, would you still have found our emails hostile?
I would appreciate answers to my prior questions, which you didn't address. Were we more hostile than simply turning everything off? It was a binary option. We chose to give people years of choice instead of deleting their photography.
When I see the home screen, I am presented with 3 friends with pro accounts, who have been using your service for years. Some as long as I have. F1: last upload 2011, F2: last upload Oct 2023, F3: 2021. What this says to me is that people are paying for storage and are not actively using the site. The non-paying friends are 1-5 years ago. Those aren't customers, those are people who fell into the trap of paying for something because it was a lower bar than migrating somewhere else.
Of course what I see is different than what you see, that's why I think our perspectives are so different.
I'm sad that you keep dodging what I view as the more important questions after you accused us of "actual hostility", though. I'd really love to understand how we missed the mark for you, and how we've been hostile, in case that applies to non-outliers and it's something we can improve on.
Was offering years of downloads on a _free_ service hostile? In what way? Was delaying deletion to give more people more time to download hostile? Why? Do you really believe hundreds of millions of consumers all had backups? What other similar Internet services are better examples of handling a situation like this?
Or are you just trolling and I've been feeding a troll (if so, congrats, I feel like my troll detection is relatively high)?
> I'd really love to understand how we missed the mark for you, and how we've been hostile, in case that applies to non-outliers and it's something we can improve on.
I thought I answered that above:
"Sending a FINAL NOTICE and then a more friendly reminder, and then not doing anything, is hostile behavior intended to extort people to pay money for a service that really hasn't seen any improvement in a very long time."
---
This conversation got me thinking about the history of things given that I've been a member of that site for 19 years. So, I went searching. This is a pretty good article I ran across from 2019:
https://ferdychristant.com/the-rise-fall-and-resurrection-of...
I find that little has changed since that article was written.
Let's start with the facts:
1. You have a free account and pay $0 for the service.
2. You received a few emails informing you of our choices when we changed the free account policies and limits.
3. Your choices included downloading your content, paying for the service, and/or closing your account.
4. You (and everyone) then got more time to make your choice than we'd originally said, for free.
5. Your account, for some reason, hasn't seen some of these changes, so you got even more time to make some of those choices, again for free.
None of that sounds hostile to me. I'm not sure who would consider that behavior hostile (more choices, more time, at $0 cost). Despite the depth of the conversation, I'm still struggling to understand (but, surprisingly, still open to the idea of) how we can be accused of "actual hostility".
Now, let's take your false statements:
- "not doing anything": I can assure you we've done many things, to many accounts. Using an online search engine will reveal plenty of examples. Why has your account not seen some of them? I don't know, but speculating that we haven't done "anything" is simply not true. Even your account has seen many changes, perhaps just not the one you highlight (removing your excess private photos). Try uploading more than 1000 public photos, as just one example of doing something.
- "intended to extort people": Simply not true. The choices were clear and the timeline was, and in your case, remains extremely generous. I happen to know the intent (not deleting any photos for as long as we possibly can) and you do not. Further, every action we've taken supports this intent. We didn't, and don't, hold any photos hostage for payment or anything else. There was no extortion, and there was certainly no intent to extort.
- "hasn't seen any improvement for a very long time": While it's possible you haven't seen any of YOUR preferred improvements, the list of improvements since we took over is long and consistent. We're averaging ~10 material improvements in the form of new features, upgraded features, and significant bug fixes, each month, for the last ~5 years. (Thousands of minor bug fixes, too) They're all well-documented on our blog[1] and in our help forum[2]. Our members agree, based on all of the feedback and data we see.
I typically love conversations like these, with "delightfully discontent" customers, because that's where the real value for learning and growth usually lies, not the thrilled customers I tend to meet day in & day out. I want to learn something here, so I and we can improve. It hasn't happened yet.
We clearly fucked up - you're upset, and you're bothering to engage. I just can't figure it out. Probably my fault. But I'll keep trying. :)
[1] - https://blog.flickr.net/
I see this as a masterclass on how to fail to convert a 19 year member of a website, back to a paying customer.
Yes, I used to pay for Flickr Pro. I stopped when I found that it wasn't providing me value other than "we will delete your private photos" if you don't pay up.
By the way, I did at one point look in the UX to see if there was a way to be able to view just my private photos so that I could delete them myself, but it wasn't obvious in my searching. It felt like it was intentionally difficult to even see if I wanted to keep an account.
Never once did he ask the simple question: "What can we do to convert you into a paying customer again?". Everything has been some sort of weird truth seeking mission to prove me wrong.
The fact that he even engaged with you at all, and to the degree he did, was incredibly kind and he showed much restraint, kudos to him for that.
But you continued to double-down on your opinions and think you're more important and worthy of his time than everyone else. Why is that?
Never once asked for that. Although, let me remind you that he does in fact make money off driving traffic to my public images (and everyone else's as well). If he wants to give away that service for free, it is his business choice to do that.
> The fact that he even engaged with you at all, and to the degree he did, was incredibly kind and he showed much restraint, kudos to him for that.
Agreed. Kudos to him!
> But you continued to double-down on your opinions and think you're more important and worthy of his time than everyone else. Why is that?
I guess it is my fault for sticking to my opinions. ¯\_(ツ)_/¯
I don't appreciate you basing your response on the idea that I'm a $0 service customer, so that I shouldn't expect anything. Nothing is ever free. My public photos drive clicks to the site and therefore paying customers. I don't get paid for that service, but you do.
We are going to have to agree to disagree on the emails. You say "simply not true", but ignore the simple fact that unless I pay for something that was previously otherwise zero cost, my photos will be deleted. Your counter argument to that is that at least the site is still up and running or that I can download the photos I already have archived. Again, that's your choice to try to bring the site to profitability, for your own financial benefit.
I'm glad you have so many happy customers. Seriously! I'm also not upset or angry and I don't appreciate being boxed in like some freeloading curmudgeon. You asked why one would move on from one of your services and I responded in kind with what I felt was valid feedback. Nothing more, nothing less.
"Reminder: Your account is in violation of our free account limits."
So, here is my question... is it easy to locate AND change the privacy settings?
The instructions suggest that I can't search for my private images AND simply remove or change the privacy of them.
https://www.flickrhelp.com/hc/en-us/articles/4404078163732-C...
See also: the directory https://github.com/relink2013/Awesome-Self-hosting-for-the-w..., that collects "self-hostable services with native mobile app clients." This project should be on there! (Right now, the only entries in the Photos category are two [closed-source!] Synology offerings, and one other app that's not E2E-encrypted. You're better than these — go claim your crown.)
We've a discussion to add an option in-app to configure the endpoint @ https://github.com/ente-io/ente/discussions/504
If all the applications are free software, it's obvious you can do that even if it means recompiling it (minus for iOS, sorry) — I believe it's ok if they have the option described somewhere deep in a FAQ or on-prem setup instructions.
But the very fact that the best directory for this kind of thing that I could find, is so spartan and unmaintained, tells you a lot about how rare this combination of features is.
And thank you for the pointers, we'll try to get ourselves added here :)
[1]: https://github.com/awesome-selfhosted/awesome-selfhosted
[1]: https://www.calculator.net/permutation-and-combination-calcu...
About auth, I'm not sure the claim in the readme is entirely correct:
> Two years ago, while building Ente Photos, we realized that there was no open source end-to-end encrypted authenticator app.
Surely bitwarden existed and had 2fa support two years ago? Granted it's not only an authenticator app...
Ed:[I guess 2fa is/was a pay-only feature, so only source-available? ]
Looks like auth is a great dedicated 2fa app by the way, surprised I've not come across it before.
Also, the feature to store 2FA tokens is only available on Bitwarden's paid plan, while with Ente it's free.
Not totally. It still protects from the password being disclosed via other means (e.g. server db leak).
But that is also why I'm not overly concerned by the bitwarden model: in client compromise (ie phone), attacker gets both password and totp secret. But so too in many examples of server compromise.
Seperate totp app doesn't really mitigate any risk factors - but a seperate hw token/device do.
You could have 2fa only on phone, password manager only on desktop - but then logging in anywhere on your phone is inconvenient.
Then again: "Security is not a convenience".
Cool app, even better now that the server code is open source !
So, I am traditionally somebody who self hosts a lot of stuff. I am not allergic to paying a fee to have something hosted by someone else - but one of my conditions to doing this is that there is an easy way to migrate away from the cloud offering should I choose to in the future.
To give an example, I use Tailscale HEAVILY right across all my self hosted stuff. It is absolutely central to everything I do - and I'd find it very hard to live without it. I am totally comfortable with this because Headscale exists, which is an open source implementation of Tailscale. If for some reason Tailscale starts making decisions I don't like, or perhaps the pricing changes in a way I am not a fan of, I have the option of trading some convenience.
I am really happy to see your server is open source. That is amazing news, and makes me feel a lot more interested in your product. I wanted to ask a few questions though:
* Let's say I've signed up with your service, and am hosting a bunch of stuff with you. I decide after 6 months I don't like some changes to the pricing model or something. How does one get their data out of the `cloud` ente.io - and into a self hosted instance of the server? Is there any data loss during this process?
* Your clients are not open source. I totally understand this. Do they however support talking to a different backend (like for example a self hosted Ente instance)?
* And finally - how would you say your tool compares to the two main open source Google Photos replacements, Immich and Photoprism?
> data out
You can use our Desktop app[1] or CLI[2] to export your data, incrementally. There's a toggle within our Desktop app that will perform this operation continuously into a directory of your choosing. You can of course script the CLI however you'd like.
There is no data-loss, you export what you import.
> clients are not open source
Our clients have always been open source. You can find them within our monorepo here[3].
Currently you have to pass a flag at build time to configure the endpoint, but there's a discussion[4] to add an option in-app instead.
> Immich and Photoprism
Ente comes with e2ee[5] and replication strategies[6]. The former means that we've to run ML on the Edge, while Immich and Photoprism can run ML on their servers. If your primary use case is self-hosting, Immich is the more "intelligent" option. If you value convenience, Ente is the one.
[1]: https://ente.io/downloads/desktop
[2]: https://github.com/ente-io/cli
[3]: https://github.com/ente-io/ente
[4]: https://github.com/ente-io/ente/discussions/504
Just to jump in cause I was curious myself. I think your question is answered here:
"Command Line Utility for exporting data from Ente"
[1]. https://twitter.com/VishnuKVMD/status/1253324405813284868?t=...
I guess I'll stick with Immich [2] for now.
Edit: Found a Reddit AMA [3] from the CEO and I'm happy to know that self hosting is a goal in the long run.
[1] https://github.com/ente-io/ente/issues/141 [2] https://immich.app/ [3] https://old.reddit.com/r/degoogle/comments/116fx9v/ama_im_vi...
The only downside for me is that there's a new release almost every couple of days, with a message that the backend is out of date. Which is both a pro and a con, but for me it's anxiety inducing because there's breaking changes sometimes and you can't just auto-update. A pace like Home Assistant feels more comfortable.
It's a great software but I would not recommend it at all because of this and the answer from the authors about the issue
I have been using it for some time now, and none of the "breaking changes" broke anything because they have excellent release notes.
Worst case - you can restore your postgre backup (which you make, right?) and try again, reading release notes. I make backups and I read release notes, luckily didn't need to do a restore yet.
That sounds pretty horrible tbh. Yeah you should make backups and read release note but if the software regularly needs some manual action then that becomes tiring pretty quickly when you host enough different services. Backups and manual intervention for upgrades should be for exceptional cases.
Running REINDEX TABLE USERS; on the DB solved the issue for me.
Immich is definitely fast moving - it is awesome, but has been a challenge to keep it current.
The project is under very active development. Expect bugs and changes. Do not use it as the only way to store your photos and videos
I self-host on my own local server on my LAN (an RK3588 ARM SoC board running in a cigar box...) and expose it to the app via Tailscale when I'm out and about. Works great
Though I still back up to Google Photos as well
I would gladly pay $10-20/mo for Ente apps to use my own backend. Unfortunately I have around 8TB of photos so paying for a storage plan is out of the question.
It seems more likely this is only open source for audit/transparency purposes.
It’s absolutely their right to do this, but they should make it clear.
Addition of an option in-app is being discussed @ https://github.com/ente-io/ente/discussions/504
I've exported from a rooted phone from Authy->Aegis->Ente Auth.
I have no need for their main product but they are building amazing software!
There's a discussion here on PrivacyGuides, that might offer more details: https://discuss.privacyguides.net/t/add-2fas-authenticator-a...
Out of curiosity I checked Dropbox:
https://www.dropbox.com/plans/storage
9 USD per month gives you 2TB storage (vs. 500GB here)
I don't really get what justifies the 4x price (some of the features look like what you can get from a Gallery app like Aves) So it's looking kinda DOA to me.
The intersection of people that care about open source and people that want to backup their photos also seems really minuscule. If Dropbox goes rogue and you need to switch providers.. that doesn't seem like a big deal? It's nice here that you can in theory selfhost and keep using it.. but that doesn't seem like "a big win" either. Most people that back up their pics in ~the cloud~ won't have the technical skills to do self-host
EDIT: There is a comparison: https://ente.io/compare/ente-vs-dropbox/
It seems like the added feature boils down to automatically encrypting files. With Dropbox I guess you could accomplish the same, but you'd need to encrypt manually. Maybe for people with a lot of dick pics or illegal material this product is worth the 4x price
And that's probably better for them, because it's much easier to lose data from your own NAS than it is for a cloud storage provider to do so.
> Most people that back up their pics in ~the cloud~ won't have the technical skills to do self-host
Which is why they are offering a managed service as well. Even people with the technical skills are not always inclined to selfhost.
> With Dropbox I guess you could accomplish the same, but you'd need to encrypt manually. Maybe for people with a lot of dick pics or illegal material this product is worth the 4x price
Privacy is for criminals and storing CSAM, right? Why would you even want Dropbox at this point, Google Drive is all you need. Unless you wanted to help diagnose your child[1] and unfortunately the photo was synchronized to Drive and flagged.
You have every right to expect your photos to stay private. Even if those are just a landscape. Why should you be obligated to have an AI scan them for offending content or scan them to detect who you met and when (surely so they can build a yearly recap for you, how kind!)? Did you ever get consent from everyone on your photos for this sharing and processing?
You may not be interested in E2EE or open source, and that's absolutely fine. But you shouldn't actively undermine it by associating encryption and privacy with crimes.
[1] https://www.theverge.com/2022/8/21/23315513/google-photos-cs...
You just need to look at Signal. It's at the same price ($0) as its competition (not 4x). And messages you can't really encryption yourself. It's still struggling to get a market foothold.
Yeah, it'd be great to have Google/Dropbox/etc with privacy. Sure. Nothing wrong with that. But you also have to pay the bills and feed your babies. This isn't a charity. Maybe I'm missing something, but this product make no sense in the market. They can't even match the market prices. They're toast
If you are techy, this is made to be shared with families and friends, which won't do that.
Obviously there's a question of whether people in the latter group may end up in the former, perhaps by mistake, but would that risk be sufficient to make them pay 4x?
This seems like a lack of imagination, which is not to be confused with any deficiency of the software or its business model. As for me, I think this completely rules.
Photos are the only reason I pay for the 2 TB plan on iCloud. I don’t need all the photos on device all the time. If I can _reliably_ stash them in remote servers and have a way to access them on-demand on the phone, I can take the money I give Apple and pay for the app that enables me. But only if I don’t have to remember to open the app every now and then and watch it sync my photos. It needs to be as easy to use as Apple Photos..
Apple doesn't allow background execution for third party apps. Can't increase service revenue if you allow competition.
[1] https://github.com/ish-app/ish/issues/249#issuecomment-54433...
They make it impossible to compete, their apps have permissions no one else can have.
As the other commenters are mentioning though, this is all black magic at the mercy of Apple. The way we've evolved with our code works now, but who knows what future updates to iOS bring. One thing we've observed that it takes sometimes like say seven days for Apple's on device ML to pick up that the user really wants to use the app, and convince the OS to allow the app to run in the background to sync. But again, this is not something we've needed to worry about as _users_ - we just use it normally as we'd use Apple Photos, and it just works after the initial sync completes.
Anyone else find where they are doing anything iOS specific to enable background uploads when you don't ever open the app? Apple go to great lengths to make sure the user has to use the app before it allows "budget" for background processes to execute within.
My guess is that as part of the Ente team, you open the app semi regularly, which is enough for the device to give some budget for your cloud sync process to kick off in the background every now and then.
For me, I would set Ente up and forget it. But I'm 99% sure in that case it would simply stop syncing after a few days.
Search for "SyncService.instance.sync" in the code, that's what gets triggered.
The trigger is us sending periodic silent pushes to wake up the app.
> My guess is that as part of the Ente team, you open the app semi regularly, which is enough for the device to give some budget for your cloud sync process to kick off in the background every now and then.
I know what you think, but that's really not the case :) Many our customers are on iOS, they're satisfied with it. There are areas to improve yes - the initial import is the major pain, esp because it is also the customer's first interaction with the app - but the background sync itself is works seamlessly in practice.
You typically want to have a place for your family to manage your photos. A completely separate one for friends etc. Yet I don't see that usecase represented in software such like this (thinking of apps such as Immich, Ente seems quite similar). Managing your own photos is rather trivial in comparison, just need to sync your folder and 90% of the functionality is done.
And that is before the usecase of collaborating between participants on a trip. Or letting guests upload pictures for an event (such as a wedding). Such a hassle.
From the site: "Sync your library with your partner, and even designate them as an heir to your account." Nice, but not exactly it.
> "Can I share my subscription with family and friends? You can add up to 5 family members and share your available storage space with them at no extra cost. Each member will get their own private space, and can only access their own photos."
Almost like it goes out of their way to not support this. Seems like such low-hanging fruit. I get that storage costs could become an issue, but in a self-hosting scenario that is not a problem.
1. Album collaboration: https://ente.io/blog/collaborative-albums/
2. Photo collection: https://ente.io/blog/collect-photos/
Please let me know if I missed something. Sharing is an important feature for all of us, and we would love to get it right.
For a group of friends / family you'd probably want many tens of albums tracking different trips/events etc.
Thanks for sharing your use case, will figure out how to best solve for it.
(Right now a "stream" of photos within a feed sounds like simpler UX than nested-albums, but will think more)
I think many people forget about this. They pay for a monthly or yearly cloud storage subscription, but forget they have to pay this amount every year for the rest of their lifes if they want to keep their data. That's why I also use a Synology disk. I also have an additional lifetime subscription at a cloud storage provider (which pays back within 3.5 years). Sure they can disappear after say 10 years, but at least I have the Synology and I got a much better deal during those 10 years and can look for something else.
Another thing, don't upload all pics you take immediately, only sync after you have cleaned out all the bad photos and near duplicates.
It's unlikely that people are using SSDs for the main storage on a NAS though, commonly just used for smaller parts (think metadata in ZFS-land for example), not for the main storage. Precisely for that reason.
SSDs use flash memory cells, which have a limited amount of writes you can do to them before they start to fail. Compared to magnetic disks in HDDs that don't have a finite lifetime of writes.
If you are mostly reading data, then no worries, probably won't affect you. But NASs typically gets a lot of writes, so you want something more durable than SSDs (in terms of writes).
Sure, if you upload 10 photos a week and never do any other reads, go with a SSD for all I care, it'll last long enough.
Solution: a RAID system with 5 reliable disks and you replace 2 of them every 5th year, and the other 3 in the following 4 years.
RAID is only useful as long as you don't suffer more simultaneous disk failures than you've provisioned for (where "simultaneous" is dependent on your time-to-repair, since if it takes you a week to replace a dead drive, then two failures in the same week are indistinguishable from two failures in the same minute, in that you've lost the entire array).
Depending on how much data you have to archive and frequency of access, it may very well be worth the cost to entirely offload opex and capex to cloud storage.
AWS Glacier Deep Archive in us-east-1 is $1/TB/month (GCP and Azure offer comparable pricing for archival storage). If you have 5x 4TB SSDs that, say, run you $200 each, and you run RS(5,3) then you're storing 12TB of data for $1000 of capex for 5-10 years. Meanwhile AWS would set you back $144/year, so the breakeven on capex alone would be if you would normally rotate your disks every 7 years.
And yes, my wife regularly looks at photos from 3,4,5 years ago, or older.
But you might still have some value in using Glacier for archival purposes and having somewhat less resilient local copies (e.g. only being able to tolerate a single disk failure, or even just JBOD).
Either way, your current approach clearly works for your circumstances, even though it'd be too fiddly for me personally.
In any case a NAS with 5 disks is probably overkill for family photos and videos, a single disk or at most a RAID0 with 2 disks over a RPi5 will be enough for many people and way way cheaper than a 2TB plan, but obviously you need to know how to and like to self-host
I personally am considering Ente right now, since having E2EE Google Photos sounds actually pretty cool, despite the fact I have a NAS (a Synology NAS, for that matter). However, my reasons to not using the NAS as you could are different: this is really the place where I store everything, so I prefer having it accessible from local network only. Not sure how you guys feel safe putting something like Synology on the open internet. (Also, I currently don't run it 24/7 anyway, but that's for different reasons, which I hope will become obsolete when I find a better place for the NAS at home.)
Have you taken depreciation into account in that calculation? Compute, memory, and storage are still getting cheaper each year due to manufacturing improvements.
I actually have 2 backups, google photos low quality backup, and the synology one.
Isn't this why offsite backups are important?
Synology has Hyper Backup, and as you mentioned, there's also rclone.
I personally think the biggest benefit to keeping photos as simple files (and maintaining my own offsite backups) is that I'm never at the mercy of one of the SaaS's microservices being down, features being nerfed, or a company being restructured or acquired.
I do see the "peace of mind" that an automatic photo hosting/backup service gives. :) Well, one could always use them all (maintaining file backups and paying for a service like Ente) for real user-side redundancy and convenience.
Repo here: https://github.com/ente-io/ente
Btw, in contrast, Google has 100$/year/2TB, so a bit less. (https://one.google.com/about/plans)
However, I am lucky that almost all my photos/videos at Google Photos were either uploaded when it was still not counted towards the storage (and that did not change for the previously uploaded media) or made with some older Pixel phone, where photos/videos in high quality were also not counted, i.e. unlimited storage. My current phone is a Pixel 5, which still has this feature, but it's unfortunately the last Pixel phone where they had this, and support of this phone ended September 2023.
I'm not sure what to do when I cannot use this phone anymore. Change my habit to make less photos/videos? Or just self-host. I could maybe also filter the media a bit, but I'm somewhat too lazy to do that, and I hope that some AI could maybe anyway do this automatically for me, and I don't really like to delete things, even if they seem maybe not so great quality right now, but it seems like they still might have some value, and storage is cheap.
Works perfectly fine.
I guess it's a good thing Ente might become a viable self-hosted option in the future. I haven't tried the hosted service, but a metadata export guarantee could be huge in attracting paying users for which this is a concern.
[1] https://www.theverge.com/2016/8/22/12587656/picturelife-shut...
That said, I understand your concern.
Open-sourcing the server was a step towards ensuring posterity. Pricing ourself sustainably from day #1 was another. We'll have to do a lot more work on this front over the next few decades and eventually find someone aligned with our ethos to pass the baton to.
I find this to be a very interesting problem to work on :)
Some bits of the blog post are outdated, since the feature has matured since then. But the implementation details are roughly the same.
TL;DR: The keys are added to the URL fragment (the part that follows the #), and these fragments are not accessible to the server.
This at least has a user accessible cryptographic identity, so end to end secure key exchange is possible. So if you really wanted to call it end to end encrypted, it would be legitimate to do so. I suspect that the motivation here is still mostly marketing driven.
I wonder how the big players do it. Of course they have a lot more manpower, but maybe the also have some clever caching/rendering lib..?
Kudos for doing this and opensourcing everything. I really appreciate this and I might stick around.
We currently keep 2 versions of a photo - one the original, and the other a downscaled copy to be rendered as the thumbnail.
Unlike non-e2ee providers, we cannot transcode and serve optimised images on the fly, when it's faster to downscale than serve the original image over network.
What we could do is
1. Intelligently preload original photos when their thumbnails are in scope
2. Store an extra version of the photo, whose resolution is between that of the thumbnail and the original, and perform #1 over those
Sorry about the flicker, will fix it.
If only there was a progressive encoding which lets you get a perfectly downscaled (not blurry) version of an image by just reading parts of the file.
We currently render the thumbnail first (in most cases it's available locally) and then replace it with the original image once fetched from remote, while replicating the zoom and pan operations (if any) performed by the user. So it is "progressive" in some sense, but goes from something like 20% to 100% in one shot.
("20%" is a simplification, the actual value will depend on the resolution of the original image and that of the generated thumbnail, the latter is fixed)
Kudos on the Ente team!!
Which brings us to self-hosting, of course: really nice that the server is open source! I found ente first through f-droid when the app landed there but put it aside because the server was closed-source then. But wow, really nice design! I like the docker-compose just shoves a minio in there, really neat and probably how I would build something like that myself if i would start from scratch.
Compared to photoprism and immich, for sure server-side machine-learning is missing, but then that's obviously a tradeoff you must live with if you want E2EE.
As I mentioned in the goodbye note, I won't be using this short term because I do need to have something on my desktop I sync photos with that's not a bulging pile of Chrome (AKA "electron"). I really appreciate you spent all that energy writing those apps, but I really need something more lightweight on the desktop.
Right now I'm syncing photos with git-annex, and I wonder if ente could be a "special remote" there, even, but for now this is not really compatible with my workflow.
But congrats on this tool, it looks really nice and I'm likely going to recommend this to friends and family as a hosted solution.
So, what's the catch? Is 500 GB photos on Google Drive actually "most users"? Is there something with that service that would prevent me from staying within 50 GB? Like, maybe it's impossible to delete a photo later on? This is a serious question, 500 GB of photos for "most users" seems absolutely nuts to me.
In that case I guess 500GB make sense.
I do not need heavy transcoding or stuff. Just a place for people to dump their photos on.
I have looked at some alternatives but they are all resource hungry from respective docs.
If pixelfed can run on php and limited resources , why not some google photos alternative?
Is there something lightweight that let's multiple people to share their photos together.
I have attempted to use pixelfed but that's stupid as it only let's 4 photos per post. Urrgh.
People would upload, backup, share their photos and media.
Its not in a single place so I can't use local sync and stuff.
(disclosure, I'm one of the Immich maintainers)
I‘m absolutely fine with having the ML run on my Desktop as long as it syncs to the phone as well.
iOS does the same. They cannot do it on the server because they don’t have access to them.
As for iOS, Apple controls the whole stack. Whatever ML they do, they do it only on devices capable of that level of ML.
I can buy the cheapest android I can find with a 10 year old mediatek processor and search for pictures of my dog and it'll show it. There is a value to doing the heavy things on a heavy hitting server.
We have to pick our battles, and we currently aren't looking at serving customers on low-end devices. But if they access Ente on a laptop, the indexing will run there, and the computed indexes will sync to their low-end devices, e2ee.
Also, given that compute on smart phones is getting better and cheaper with every iteration, we believe it's best to bet on Edge ML for the long term.
I wanted to share my view as a regular person, sadly for whom absolute privacy is a feature and not a necessity, which I think is the vast majority.
Good luck; hope you guys figure this out.
A fellow Malayali :)
We do get your perspective. Privacy does not outweigh convenience for vast majority. We are hoping to find the balance.
You’re comparing apples to oranges. Google Photos is not E2E. Explain how you can do ML without having the key. Either you hand them the key or you don’t.
Of course they mention it as an alternative to Google and Apple Photos, but that doesn’t imply that they have 100% of the feature set of each.
Most of our costs come from keeping 3 replicas of your data: https://ente.io/reliability
We could perhaps reduce the replicas from 3 (2 hot, 1 cold) to 2 (1 hot, 1 cold), and lower our costs, but it's not something we've actively thought about.
Also, our prices are designed such that the business can run sustainably, and we believe that's the best way to build Ente, where the expectation is for the company to outlive its customers.
https://github.com/ente-io/ente/tree/main/server#self-hostin...
However, one feature that I love about PhotoPrism is the performance. I have about 120.000 pictures on my Raspberry Pi and for the most part, the experience is flued (just try opening a picture and hold the right arrow key on your keyboard (just try it in the demo)). I have had local solutions that had problems with that amount of pictures and this one works via network. Other features like face recognition, automatic labels, or the map view are cool too.
Photoprism has a feature list [1] and a demo [2].
Ente now has everything except cross-platform face-recognition (it's desktop only right now), labels and EXIF edits. The first two are being worked on, we should have v1s ready by Q3. Polishing will take a bit longer.
The long-press-to-skim-through albums is very neat, will add this.
I currently use photoprism, which is good, but i’m always on the look for a great self-hosted photo app.
1. Takeout to Google Drive :grimace:
2. rclone from Google Drive
But I do this around once a year, and the last few times there are new roadblocks every time.
"Similar messages were used to steal people's personal information. Avoid clicking links, downloading attachments, or replying with personal information."
So you know
If there are any experts reading this, we'd be grateful if you could let us know what we're doing wrong here.
We're in the middle of switching over to SES because they are landing flawlessly into Gmail inboxes, but it would still be good to understand what we could have done better.
Now that Ente has open source server, and incremental backup, I'm in!
etesync is the other service I'm happy to pay for.
Edge is an overloaded and fuzzy term [0]. It just means "on device" here, right?
[0] https://www.cloudflare.com/learning/serverless/glossary/what...
I agree that "on device ML" is less ambiguous, so will give this some more thought.
Thanks for the suggestion!
> all the computation must be done on the edge: your own device.
Might do the trick.
Compare this to the approach of CSP's, their model is mostly around "trust me bro", and even on enterprise/commercial terms the transparency they provide is poor. I would love to see this sort of transparency by service providers in the future.
Yeah, searched "ente.io": *cricket*
Also no encryption-at-rest capability: https://github.com/immich-app/immich/issues/450
Looks like we've quite a bit of "ASO" work todo. Thanks for the heads up!
Regarding encryption, the link you shared points to Immich. Ente uses client side encryption, so your data is encrypted before it leaves your device, and only you have the keys to decrypt it.
Ente's strength lies in end-to-end encryption[2] and its cloud[3] offering so you don't have to worry about reliability.
So if self-hosting is what you're after, Immich, Photoprism and Damselfly (TIL!) are perhaps better designed to serve your needs.
[1]: https://github.com/photoprism/photoprism
edit: found it: https://github.com/ente-io/ente/tree/main/server#self-hostin...
Currently you've to pass build time flags[1] to modify the endpoint.
Providing an option in-app to change the endpoint is under discussion[2].
[1]: https://github.com/ente-io/ente/blob/main/server/RUNNING.md#...
We all want cool things, secure, where our data is protected and we are not the product, but 3 euros a month is too much?
No wonder big tech gets bigger and the rich get richer. The silicon valley VC funded feifdoms become more entrenched and, in the end, we all suffer for it
Over a 10 year horizon, the difference between 1€/m and 3€/m is a mere 240€.
That's like 2-5 extra work hours over the course of 10 years!
I seriously don't get how someone working in tech would fear bankruptcy over this.
Now Ente could of course choose to keep lesser replicas and offer "lite" plans that are more affordable. But we would rather not complicate our pricing structure right now. Understanding buckets of GBs is hard enough, and adding tiers on top would worsen the experience for most.
All of that said, Filen does seem like a really cool project for storing files.
You can read about our replication strategy here: https://ente.io/reliability
We could in the future offer cheaper plans at the cost of additional replicas.