Super excited for this one.
Show HN: We built an end-to-end encrypted alternative to Google Photos
171–180 of 421 posts
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#172[deleted]
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#173Please please support custom storage back ends, I'd love to use my Dropbox or S3 or whatever to still fully own my pictures. And I'd love to pay extra to opt out of and analysis, tagging, etc of my photos. Basically I'd like the interface to be similar to Google Photos but with a privacy focused storage engine and clients.
I concur. However storage is how they plan to make money, so there will need to be a different monetization strategy for BYO storage. As yet I can't imagine any. EDIT: I think have an idea! Add the S3/OneDrive/Etc support but comment it out. To make use of it one would have to download the source, XCode, compile it, and deploy it. This puts a cap on the number of people who can do that, so you won't end up with every…
So it's a little more complicated than that.
Our API server runs the following
- authentication
- replication
- differential sync
- and a few more errands that are necessary for the apps to function
The solution to this would be to offer a self-hosted variant where you can plug in your S3 credentials. But like I mentioned else where in this thread, maintaining such a project comes with an overhead we cannot afford right now. Hopefully sometime in the future we will be able to afford the necessary engineering bandwidth.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#174Earlier quoted context omitted.
As someone who has worked on systems like these let me translate: “You stuff will be private but in return accuracy will be so bad that the UX is gonna suck!” That’s the key piece people miss when they wanna do anything with ML…that’s it’s a different problem compared to writing code because it’s not about the code anymore, it’s about having great training data!
Apple Photos seems to be using just Core ML[1] for on-device recognition and it does a pretty good job. As for Android, we plan to use tflite, but the accuracy is yet to be measured. And if customers do install our desktop app, we will be able to improve the indexes by re-indexing data with the extra bit of compute available. We don't feel that the entire UX of a photo storage app will "suck" because of a reduced acc…
Up until recently I’ve used Apple Photos happily since it provided a good combination of convenience plus the privacy of on-device recognition. You have a compelling product if you can convince customers you are as reliable and more trustworthy than Apple. You do face the disadvantage of not being the default option for iOS/macOS but that should be balanced by being available cross-platform in Android, Linux, Windows.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#175Earlier quoted context omitted.
Am I the only one who never realized you can search "museum" and see your museum photos? Now that you've mentioned it, yes, I'd like to try that. But as a counterpoint to your argument, I've never needed it, and I suspect that a lot of people may not actually be getting the same value propositions that you're getting. On the other hand, Google Photos is Google Photos. But it's often a mistake to compete directly with…
I use it all the time - it's the killer feature of google photos. The premise is that if you come back from vacation with 300 photos, it's unlikely that you (the average non photography-nerd user) are going to sit there and tag them all. If in a few years you want to find "that photo of me you took on the beach in north carolina", with a quick search you can. There are annoying limitations though, probably because th…
It's a great idea that works in a limited way. Getting that next 30% is going to take awhile nevermind natural language queries.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#176Your homepage says "protect your photos/faces etc. from algorithms" The algorithms are what makes Google Photos; Google Photos. If I wanted to just store my photos I'd throw them in a S3 bucket or Dropbox or something. Google Photos lets me automatically categorise my photos by person, lets me search my library using text search for anything (e.g. I can search 'museum' and see pictures I've taken in museums). That is…
I want none of those features.
I want automatic backup, easy sharing, and accessibility from all devices.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#177Your homepage says "protect your photos/faces etc. from algorithms" The algorithms are what makes Google Photos; Google Photos. If I wanted to just store my photos I'd throw them in a S3 bucket or Dropbox or something. Google Photos lets me automatically categorise my photos by person, lets me search my library using text search for anything (e.g. I can search 'museum' and see pictures I've taken in museums). That is…
>lets me search my library using text search for anything
This is untrue, and actually one of the reasons I hope a strong competitor to Google Photos comes along soon. The search function is, for whatever reason, heavily censored and perhaps even biased in some circumstances. Worse, it is completely useless. For example, the query "fat" returns nothing, despite the fact that my gallery is filled with drawing reference photos that includes plus-sized people. "Black people" returns photos of non-black people, and (infamously, and perhaps for related reasons re: the shortcomings of Google's image recognition and tagging algorithm) "gorilla" returns 0 results. "Red shirt" returns an image of a blue decorative screen; "comic" returns anime and webpage screenshots; "woman" returns multiple photos consisting entirely of groups of men.
The situation is dire.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#178Earlier quoted context omitted.
Without a fully described mechanism to confirm that the client you download is not compiled with additional code (i.e. without specifying exactly how the client is compiled, using which version of which compiler, and which compile flags, dependency versions, etc) any kind of "the code seems to be on github" is kind of meaningless.
Ideally they should support reproducible builds so that anyone can confirm that the hash of the app corresponds to a specific tag on the source repository. Unfortunately app stores are making it harder to know what the hash of the app you are installing is, but for side-loading this should still be possible. For web apps, the situation is even more difficult, but there is a technique called Secure Bookmarks which all…
F-Droid supports reproducible builds. Any serious FOSS app, I think, must priortise publishing to F-Droid.
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#179Your homepage says "protect your photos/faces etc. from algorithms" The algorithms are what makes Google Photos; Google Photos. If I wanted to just store my photos I'd throw them in a S3 bucket or Dropbox or something. Google Photos lets me automatically categorise my photos by person, lets me search my library using text search for anything (e.g. I can search 'museum' and see pictures I've taken in museums). That is…
> If I wanted to just store my photos I'd throw them in a S3 bucket or Dropbox or something. Neither of those give you any privacy unless you do the encryption yourself in which case you have to build something to access them unencrypted. Have you checked out what the service actually does?
Wouldn't a mega encripted folder make sense for the average person?
Re: Show HN: We built an end-to-end encrypted alternative to Google Photos
#180Kudos on your launch! I just had a question: the pricing plans seem slightly pricey, is it to break even before bringing prices down, or is it due to expensive storage? If the latter, is there a self-hosted option? Also, the website looks absolutely great!
ELI5 what does self hosting option mean here in this context?
I reckon, BYO object store.