Hacker News Reader

Comment by vishnumohandas | Hacker News Reader

Hey, over the last year we've been building ente[1], an end-to-end encrypted alternative to Google Photos.

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...

View on HN

I can't tell if this is self hosted or not. All I see is a centralized option. If not self hostable, a user still can't guarantee that this doesn't just end up being as bad as google photos. There are plenty of companies like this that provide an alternative to the mainstream then sell out. Really, the only person you can trust is yourself at the end of the day.

Hey, ente is currently not directed at an audience that has the knowledge and energy to set up and maintain a reliable storage infrastructure.

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.

You've made the right choice not to opensource and or support self-hosting options from day one.

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.

Down in the reddit comments it says it is not self-hosted because of limited "engineering bandwidth".

Hey, maintaining and providing support for a server that is de-coupled from underlying external integrations (storage, payment, secrets, email, ...) is what requires bandwidth.

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.

The self-hosted audience is also very small. I think you made the right choice.

For photos I’d agree as most customers are end users. Don’t underestimate this for other products though. Self hosting is a huge feature for selling into large corporations with data security policies.

Why would corporations want to use google photos alternative tho? They're probably are using Gsuite or Office 365 already, both of which have photo storage options. If they're okay with their emails there, I dont think photos is an issue. So yes they made the right choice, by ignore the self hosting crowd, which is a very small crowd.

It looks like they only open sourced the clients, not the backend.

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.

Hey, I'm sorry that it came across that way. Thanks for pointing it out, I now see the lack of clarity. I've updated the copy to better reflect the situation.

Great, thanks for the fast reaction!

AKA we want to lock you in to our PAAS

That seems counterintuitive.

As long as the server is closed source, this remains in the 'nice but do not touch' territory.

I got and email about this few weeks back (I must have signed up to the list at some point) but I was put off by two things.

> 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.

> "quite reliable"

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.

I am guessing he is expecting to share pics with users who did not sign up. It maybe a one time thing.

But I think you need user logged in because of encryption.

That’s right.

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.

Yes, this is what I meant and the solution you describe is what I'd be looking for. So +1 from me!

ente looks interesting to me, but I would like to have the feature to share an album with anyone who has the link. I guess that is not so easy to do though as it would require creating a decrypted copy of the photos in the album that you wish to share which would take extra time and space.

The client that is sharing the album could append the decryption key of that album to the URL fragment, such that it never reaches the server.

For example: albums.ente.io/{albumID}/!#{decryptionKey}

Now on the receivers side, the client can use this `decryptionKey` to decrypt and render the photos.

I think this is a mismatch between UK English where "quite" means "extremely" and US English where "quite" means "mostly".

I'm British and to me "quite" here means "mostly" i.e. not entirely. Could well be a misunderstanding but it should be made clearer as this data is priceless.

>as this data is priceless

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.

You're right about two being one and one being none.

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.

[1]: https://www.backblaze.com

[2]: https://www.scaleway.com/en/c14-cold-storage

Makes sense. You can feel vulnerable in a big hurry if your primary fails or if it turns out that one of your backups wasn't being properly backed up to.

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.

Doesn't "quite good" mean "great"? That was my impression, at least.

Another Brit. It's all in the context. "Quite" can easily be a strong superlative but it relies on shared understanding between the parties so I wouldn't depend on that interpretation.

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.

Not really, but it depends on context. The nuance is often difficult to detect when written. When spoken, a phrase like "quite extraordinary" or "quite brilliant" would usually be a superlative, as you suggest, but it would usually be indicated by emphasis on the "quite". And the adjective itself already has to be quite strong, so "quite good" will never really mean "great".

This is classic British understatement. It doesn't literally mean 'great', but depending on how it's said it can be interpreted as such.

I think most Brits (I am a Brit) would write "very" when they mean "extremely" rather than "quite". In spoken English there is a lot of nuance, but if you said a meal was "quite good" it would often have a connotation of "better than just okay" rather than "excellent". Saying a meal was "really good" would be closer to "excellent".

> We have shipped open-source[2] web and mobile apps that have preserved 180,000+ files.

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.

I felt that having replicated 200k files without failures is an indicator of reliability (not scale).

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.

This looks pretty neat, I wonder how I've been missing it so far.

Do you have an public API? I'd love to have a tiny sync client to fetch photos and store them on my laptop.

The API is public, but the documentation needs work.

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

Thanks! Any reference to the API, even if it's just incomplete docs?

An electron app seems like a huge overkill for something so simple (have you considered just a simple cli instead?).

The API doc is incomplete and outdated, and I'm embarrassed to share it in its current state. I will update this thread once it is presentable.

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.

What is the design target for this service? Is it the technophile who is trying to degoogle, is it some other specific design target or perhaps more general audience?

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.

What's your strategy to get enough users so that you become financially sustainable?

The current set of paid users are sufficient to break-even on the infrastructure costs.

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.

> not motivated by money

Ummm, could you elaborate on this? It sounds great but it's at the same time so foreign to me...

I am not them but I know a lot of people who are not motivated by money. I guess they need and want enough money to happily live and work in good conditions, but not more, and they do not seek to become the next Bill Gates or Jeff Bezos.

Right. But you need money to pay for infrastructure and employees.

"not motivated by money" sounds very much like "we'll be shutting down in 2 years"

"Not motivated by money" in this context simply means not being profit focused, so breaking even and/or revenue enough to hire some more engineers is probably the monetary goal

Hey, our infrastructure is already being paid for by existing users.

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.

“Not motivated by money” doesn’t mean they’re doing this out of the goodness of their hearts, it just means they’re optimizing for other things, and just see cash flow as a way to keep the lights on and their employees paid.

To me, that’s a red flag for a service I don’t want to see disappear in a few years.

Why? Not motivated by money still means they can generate income and even grow. They might not personally become rich, and they are ok with that. What's the problem?

180,000 photos seems tiny. I have about 20k photos just on my own, my wife probably has more. 180k is like 10-50 people. Not saying you can't handle it but 180k doesnt signal "I've got scaling all figured out" to me.

More than scale, it was trust and reliability that I wanted to show. Of these, I feel that scale is the simpler problem to solve.

Especially with a stateless service like a photo hosting service, this is very true.

Wish you all the best!

Everything has to start somewhere.

I have 180,000 photos in Google Photos

I’m at 93k myself…

Does this service encourages user outside EU?

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?

Hey, some of our users (and us) are based out of Asia, and have not observed latency to be an issue. We are currently tunneling our data over Cloudflare, and that helps quite a bit.

If you find observable latency within the service, please write to vishnu[at]ente.io. I will see what we can do.

As a user of ente, I can say I’m pretty happy. It doesn’t have all the features that Google has but they’ve made a promising start. If the search feature becomes comparable, I’d move off Google photos permanently.

Can the search feature of ente become comparable to Google Photos? AFAIK, ente does E2E encryption, which means that unless they index the EXIF data on each single device, and also run the image recognition algorithms on device, the search is never going to be comparable to Google Photos.

I can't live without the face / object detection. It's been so useful

If they're extracting a the fingerprints what privacy are you expecting? A pinky promise that says, we won't read your data? That would long as long is its bought by Facebook/google. Remember pinky promises made by gazillion startups?

Kudos to the name! The meaning ("ente" = "mine" in Malayalam) meshes deeply with what the service is, and it is short and easy for everyone to pronounce.

It means duck in German.

Glad you like it. :)

Product looks simple and promising as a good alternative to google photos.

Feedback: You can improve your website looks.

Goodluck

Thank you!

Regarding the website, I would be grateful if you could point out the worst part(s). I would love to improve.

Why is every string in all lowercase? It reminds me of tumblr..

We thought it looked playful, friendly that way, and less like a boring archival-solution. We liked that persona.

Are there any plans to add search and automatic image tagging ?

Our web app[1] lets you search by time ("last week", "April 14", ...) and location ("New York").

Tagging faces and objects is on our roadmap, we will ship it.

[1]: https://web.ente.io

Reply on news.ycombinator.com