We had started off as a self-hosted project, but ran into difficulties monetizing that model. We wanted to pay our rents, and continue working on this, and an E2EE SaaS was a way forward.
We are not averse to supporting a self-hosted version in the future. But that commitment requires engineering and support bandwidth, which we don’t have right now.
In my opinion open source software benefits greatly from first being closed sourced and commercially backed with an OSS release coming in the future after stability has been established.
Also, self-hosted consumer products are hard to sustain profitably. Avenues for monetization are low.
Given that our long term target audience is people like my parents, we did not see enough value in investing in a self-hosted variant, and wanted to reduce the number of distractions.
This is not to say that we are against the idea of a self-hosted variant, just that it is not a priority for us right now.
Also the phrase "ente has an open architecture and source code that has been peer reviewed" that can be found on their website follows a dark pattern: hey, look we are open but not really.
> We've already preserved 100,000+ files, and are quite reliable at this point.
"quite reliable" doesn't cut it for a paid service for me, even a new one.
My second issue, and I might be wrong about this, is that there's no way to share photos with someone who isn't a (paying) ente user.
As an engineer, I shy away from using superlatives. But sorry, I now understand that this could have been phrased better. Thank you for pointing it out.
> no way to share photos
Correction, the receiver can be on the free plan.
But I think you need user logged in because of encryption.
We could generate public URLs that contain the decryption key of the album within the URL fragment. But as an encrypted storage provider, we would like to ship this only after we're reasonably confident that there are checks in place to prevent abuse.
For example: albums.ente.io/{albumID}/!#{decryptionKey}
Now on the receivers side, the client can use this `decryptionKey` to decrypt and render the photos.
Personally, I'd never trust the only copy of something important to a service provider--especially one that isn't a "big name." (Though even in the case of big names there can be issues with account access, etc.)
ADDED: Curious why people find this a controversial statement. I understand if you have AWS set up with various redundancies but even a service like Backblaze I consider a belt and suspenders-type backup. This is in no way a commentary on the OP but simply an acknowledgement that stuff happens.
Our current setup includes primary backups to BackBlaze[1], and eventually consistent replications to Scaleway's cold storage[2].
We would like to offer an extra replica as an addon in the future.
I know a lot of people these days are fine with their stuff mostly just being stored in "the cloud" someplace. But for things like photos, I really want a couple copies under my control to the degree possible.
It's fine in a spoken context as tone can add sufficient extra meaning. If you can guarantee the listener is expecting an informal register then it probably also comes across as a superlative. "I met him and he's quite unpleasant" would usually imply he was a total c*nt.
Is that the total number of files on your platform? Not to be rude, but is this supposed to be impressive or reassuring? My photo collection is approaching half that number, and I'm just one person, so now I'm feeling completely underwhelmed by the claim.
But you're right, the number is minuscule compared to where we are hoping to be. We're just getting started and I'm hopeful that we will 10x this number in the next few months.
Do you have an public API? I'd love to have a tiny sync client to fetch photos and store them on my laptop.
If your current use case is only to sync your uploaded files to a local folder, we have an Electron app that does just that: https://github.com/ente-io/bhari-frame/releases/tag/v1.0.3
An electron app seems like a huge overkill for something so simple (have you considered just a simple cli instead?).
The Electron app is indeed an over kill (hence the repo-name "bhari", meaning overweight). But it made it easy for us to reuse stable code that performed authentication, decryption, data-sync, etc. Also, we did not want to commit to the overhead of maintaining another stack (say a CLI or a native app) at a point where the value it would provide to a customer was unclear.
If it’s degooglers then perhaps convincing us it has everything Google Photos had is job number 1. If it’s missing feature X then you’ve got a reason to say no, if it’s at parity then it comes down to whether we trust YOU and is the deal good enough.
You’ve already convinced us you’re not Google so there is some things implied but you need to lean into it. Privacy, not having you information used for ad targeting, never sharing our photos or information derived with third parties - those are all thing to highlight (be the anti-Google).
I think you need some other killer feature or appeal that makes you different than iCloud here since Apple are already the anti-Google. I think you can also get 2TB of iCloud Photo storage for $10 a month so you gotta hit that if you want to charge $15 for 500GB.
As for personnel costs, a few more hundred paying users and we'll be set. Feedback from existing users have been positive, and we should be able to reach that point by end of the year.
It helps that we're living in one of the cheaper parts of the globe, and are not motivated by money. We're building this because an easy to use, privacy friendly alternative needs to exist.
Ummm, could you elaborate on this? It sounds great but it's at the same time so foreign to me...
"not motivated by money" sounds very much like "we'll be shutting down in 2 years"
Our pricing plans are designed such that you cover your own storage + bandwidth costs, and then some more. We don’t have a "forever-free" plan, and don’t intend to have one.
And the compute requirements for a product like this are low (since most of the computation happens on the client).
So currently what we need money for is employees (engineers) and not infrastructure.
Wish you all the best!
What about latency concerns for people who are not based in EU? I saw on that website that the servers are hosted in EU, and say I need to use it in Asia will have service have usable latency?
If you find observable latency within the service, please write to vishnu[at]ente.io. I will see what we can do.
Feedback: You can improve your website looks.
Goodluck
Regarding the website, I would be grateful if you could point out the worst part(s). I would love to improve.
Tagging faces and objects is on our roadmap, we will ship it.
[1]: https://web.ente.io
We have shipped open-source[2] web and mobile apps that have preserved 180,000+ files. Apart from cross-device sync, you can share your albums end-to-end encrypted, and filter photos by location and time.
We recently had a "successful" launch on r/degoogle[3]. We wanted to Show HN after incorporating the feedback we received from there, but since OP asked, I thought I’ll drop a comment here.
If you’ve any questions, please ask.
[1]: https://ente.io
[2]: https://github.com/ente-io
[3]: https://www.reddit.com/r/degoogle/comments/njatok/we_built_a...