My dad's Minolta witnessed some of the best bits of my childhood. While I remain
shy of the camera, I'm grateful for all that he captured. On the rare occasions
I flip through his albums, they ground me to my roots.
30 years later, my daughter is growing up around phones clicking even more
photos. While her very best moments go uncaptured, the rest end up on Ente. I
hope she'll be grateful for some of these memories, we are.
This cross-generational aspect to photos is something I've begun to appreciate
since becoming a parent. Posterity has become a stronger theme - I want my
family to have access to my albums when I'm not around.
To solve these personal needs we've built a feature, that we believe will be
useful to more customers in the long run.
Legacy
Legacy introduces account inheritance to Ente.
You can add trusted contacts, who
can request to recover your account. If you do not reject their request within
the stipulated time period, they will have an option to reset your password and
access your account.
All of this, end-to-end encrypted.
This is an important step in Ente's journey towards posterity. We as a company
have to outlive our people. Helping Ente last a lifetime could be our legacy.
After a year in beta, Ente's machine learning is live for all.
You can search for people, places and a lot more; while retaining absolute
privacy of your memories. Here's a demo.
We have zero knowledge of your photos or search queries. This level of privacy
is made possible by Ente's machine learning that runs locally on your devices.
Any data that's derived from your photos is stored and synced across all your
devices end-to-end encrypted. Your search queries are also processed locally on
device.
This is in stark contrast to most services, where your data is processed
centrally on their servers.
Multiple years of research and development have gone into delivering what we
believe is a novel approach to running computer vision models on the edge. Along
the way, we've overcome quite a few challenges.
We've published a whitepaper documenting the underlying novelties at
ente.io/ML.
We look forward to using this as a foundation to surface your best moments.
If you've thoughts on what makes a memory meaningful, let us
know!
Google Photos is an incredibly successful product with over 100M+ paying
customers storing a lifetime of memories. However, there are many possible
circumstances in which you want to takeout your memories from Google Photos.
Unfortunately, the tool that Google offers to do this is not the best and most
reliable (we ranted about this some time
back), as one can see from all the Reddit
posts complaining about Google Takeout
This document, therefore, is intended to be a guidebook to help you export your
memories from Google Photos for different use cases like
Migrating your memories to Apple iCloud
Keeping a backup copy of your memories
Exporting all your memories to a different service
Lets get started
What is Google Takeout?
Google Takeout is Google’s data portability project which allows users of most
of their services (including Google Photos, Chrome, Maps, Drive, etc.) to export
their data. We had written about their history
here
in case you are interested. There are two ways that Google Takeout works
Download the data in multiple zips of max 50GB and then use it how you want
Transfer directly to a selected set of services - Apple iCloud, Flickr,
SmugMug, and OneDrive
For most of the use cases, we will have to go through the zip route.
Migrating from Google Photos to Apple iCloud
This is a fairly easy and straight forward process where you don’t have to do a
lot except set it up, and wait for your photos to be transferred to the Apple
ecosystem. Lets go through the exact steps
Next, make sure you’re signed into the right Google account that you’re using
for Google Photos. You can verify and switch account, if needed by clicking on
the top right most icon in the above screen
Before clicking on Continue, also verify the albums you want to move to Apple
iCloud. By default “All photo albums included” is selected. You can click on
that and select particular albums as well. Photos that are not in any album on
Google Photos are usually albumised by year, like “Photos from 2023”, etc.
Click on Continue. Before you go on to select which service to transfer your
memories to, Google will ask you to verify your account.
This step is about setting up the service you want to transfer your memories
to. The options available are iCloud Photos, Flickr, OneDrive and SmugMug. The
exact same steps should work for all the service, but for this article, we
will restrict ourselves to Apple iCloud
Select Apple iCloud in the “Move to:” dropdown. And then click on Continue
This will trigger a sign in flow for Apple iCloud. Please complete the same,
after which you will come back to the Google Takeout page.
Before moving forwards, do make sure you have enough storage capacity on your
iCloud account, so that you don’t run into any issues while transferring
You can now click on “Agree and continue”. This will start the export process,
and you will receive e-mails from both Google and Apple notifying you of this
transfer
The export process can take a few hours or even more than a day, depending on
the size of your collection. However, you dont have to do anything else. Both
Google and Apple with e-mail you once the process is completed. After which
you can see the photos in your Apple iCloud
Note that your memories will continue to exist on Google Photos, and new
photos taken from your devices will continue to be uploaded to Google Photos.
You will have to actively delete your data and/or stop upload to Google Photos
to solve this.
Some issues we found while doing this on our personal accounts
For Live Photos, Google just transfers the image file to Apple, and not
the video file, making Apple treat it like a regular photo instead of a
Live photo
If you have some photos that are both in your Apple Photos and Google
Photos account, it would lead to deduplication. You can use “Duplicates”
in the Utilities section of the iOS app, to detect and merge them.
However, it does a less than perfect job, so a lot of duplicates would
have to be manually deleted.
A bunch of files which were not supported by iCloud Photos (few raw
images, AVI, MPEG2 videos, etc.) were moved to iCloud Drive. So your data
isnt lost, but some part of the Google Photos library wouldn’t be
available on iCloud photos
Keeping a backup copy of your memories from Google Photos
There are many ways to do this. The path we are focussing on here is for those
who use Google Photos as their primary cloud storage, and want to keep a copy of
all their photos somewhere else like a hard disk or another cloud storage.
Go to https://takeout.google.com/. This is a place where you can export your
data for most of Google’s services
By default, a large number of services are selected for export. Click on
“Deselect all”, and then scroll down to Google Photos, and click on the
selection box next to Google Photos. On the top right it should show 1 of xx
selected.
Review which of your memories are selected for export. For backups, you would
want to select all the memories on Google Photos. Click on “Multiple formats”
to make sure all formats are selected. Similarly make sure that “All photo
albums included”. You can also choose which specific formats or albums to
export in case you want that
Now you can scroll to the bottom of the page, and click on “Next step”. This
next step is about various options for your export
There are 3 sections here you have to choose the options that works for you
Destination - Where your exported files are going to go
If your backup location is one of OneDrive, Dropbox or Box chose that.
Make sure you have enough storage space on these services
If you want to backup on a hard disk, or other cloud storage provider
you can choose either Google Drive or download link via email. If
you’re choosing Google Drive make sure you have enough storage space
on Drive
Frequency
Given its a backup copy while you want to continue using Google
Photos, you should choose “Export every 2 months for 1 year”. Two
important things to note here
Google Takeout doesnt support incremental backups. So the export
after 2 months is going to be for your entire library. So to save
storage space, you will have to delete the old backup where ever
you’re storing this, once the new exports are available
The export period is only 1 year, so you will have to do this
again every year to ensure your backup copy has all the latest
memories stored in Google Photos
If you have other usecase - like moving into a different service or
ecosystem and stop using Google Photos, you can do a “Export once”
backup.
File type and size
Google gives two options for file types - .zip and .tgz. I personally
prefer .zip as decompression is supported on most devices. However,
.tgz is also fine as long as you know how to decompress them
For size, Google gives options ranging from 2GB to 50GB. Note that if
your library size is large, you will get multiple zip files to cover
your entire library. For large libraries, we would recommend keeping
the size to 50GB. However, if you have a bad network connection,
downloading these 50GB files might take multiple attempts.
Once you have made the selection, you can click on “Create export”. The page
will now show a “Export progress” section
Google Takeout will send you an email once the export is completed. You can
download the zips from the link provided in the email (if you had selected
“Download link via email” as destination) or go to the selected destination
(Google Drive, OneDrive, etc.) to download the zip files. Note that you only
need to download the zips if you want to have the backup in a different
location than what you chose as destination
Before downloading this, make sure your device has enough free storage. These
zip files contain your entire photo and video library and therefore might
require a large amount of device storage
Once you have downloaded the zips, you can move/upload the zips wherever you
want to act as a backup for Google Photos. This could be a hard disk or
another cloud provider
If you had selected “Export every 2 months for 1 year” as frequency, you will
get an email from Google Takeout every 2 months. And you will have to repeat
the download and upload process everytime. Note that you can delete old zips
once latest backups are available as every 2 months you will get a full backup
and not an incremental backup. Otherwise you will consume a lot more storage
space than required.
Please note that the above process keeps the zip files as backup. If you want
to unzip the files so that the actual photos are available, see the next
section
Moving all your memories to another service
The last section mostly covered keeping an extra backup while you’re still using
Google Photos. That’s why we kept the zip files as backup, as you don’t need to
unzip and keep the uncompressed folders for backup purposes.
However, there are definitely usecases where you would want to uncompress the
zips. For e.g., if you want to move your entire library to your hard disk, or
another cloud, you would want to make uncompress the zips, ensure your metadata
is intact and then upload it.
So how do we do this?
Make sure you have enough storage space (atleast 2 times your Google Photos
storage) on your device
Follow the steps of the previous section to download the zip files from Google
Takeout
Uncompress the zip files one by one
When you open the uncompressed folders you will notice the following
The base folder name is “Takeout”, and within that there would be another
folder called “Google Photos”
Inside “Google Photos”, you would have folders corresponding to albums on
Google Photos. Photos which are not part of any albums on Google Photos
are automatically added to year wise albums like “Photos from 2022”, etc.
Inside each album, you will see the files associated with your photos and
videos
Your photo or video media files. These would be jpeg, heic, mov, or
mp4, etc.
A JSON file with the same name as your photo/video containing all the
metadata of your memories like location, camera info, tags, etc.
There are a few issues, however, with the export files though
If your library is distributed across multiple zips, the albums can reside
across multiple zips (and uncompressed folders) which needs to be combined
together
The media file and the corresponding metadata JSON file can also be in
different zips
Because of this, when you import these uncompressed folders to another service
directly one by one, it might lead to loss of metadata associated with your
photos. It might also create incorrect folder/album structure
All you need to do is add all your zip files to this tool, and it will
do its work - combine all the photos/videos and their corresponding
metadata together so its readable by any other serice
If you have some tech know how or dont want to pay the $24 above, then
this is a library that will come to your rescue
It works pretty much the same way as Metadatafixer, except you need to
uncompress the zips, and move them to a single folder. You can find
all the instructions
here
Once these fixes are done, you can import the output to any other service or
your local storage without the loss of any metadata. This will also work if
you want to move your photos from one Google account to another
Moving your memories from Google Photos to Ente
If you want to move away from Google Photos to another service, Ente
Photos is the way to go. It offers the same set of features as
Google Photos in a privacy friendly product which makes it impossible for anyone
to see or access your photos. Migration to Ente is quite easy as well.
Download the zip files from Google Takeout as explained above. Uncompress all
the zip files into a single folder
Nine months ago, we switched to a monorepo. Here I describe our experience with
the switch so far.
This is not meant as a prescriptive recommendation, but is rather meant as an
anecdotal exposition, in the hope that it might helps other teams make informed
decisions.
Unlike most forks in the road, we've travelled both ones. So first I will
describe the history that lead up to the change, outlining how we've already
experienced the alternative non-monorepo setup too in a similar context, and
thus are now well positioned to compare apples to apples.
Platforms and monorepos
Ente began its life half a decade ago. It was a meant as a end-to-end encrypted
platform for storing all of Vishnu's personal data, but two things happened:
Vishnu realized it was not just him that needed such a thing to exist, and he
realized it was going to be a lot of work to build his vision.
So he became a we, and instead of tackling all personal data, the focus was
shifted to a singular aspect of it, Ente Photos, to get the spaceship off the
ground. To an external observer what looks like a photos app (and that indeed is
our concrete current goal) is driven by an underlying vision of the human right
to the privacy of all forms of personal data.
Why do I describe all this? Because when viewed in light of this vision, Ente
isn't a single app, it is a platform, and storing its code as a monorepo is
the ideologically appropriate choice.
This is similar to, say, the Linux kernel. Most people don't realize that the
biggest open source project in the world, by most metrics imaginable, the Linux
kernel itself, is a monorepo. Even though it is called a kernel, ideologically
it really is the full platform, device drivers and all, and the code
organization as a monorepo reflects that.
Staying close to the vision of Ente as a platform is not only about the a
ideology, but it has practical offshoots too.
For example, a few years ago, we realized that there was no good open source
end-to-end encrypted OTP app with cloud backups. So we built one, for our own
use, because it was rather easy to build it on top of the primitives we had
already created for the photos app.
Today, this side project is the #1 OTP app in the world with the aforementioned
characteristics. This might seem like a happy accident, but it isn't, this was
always the plan: build a solid platform, then one by one tackle the various
bespoke apps we'll need to best handle different forms of data.
Microrepos
So ideologically Ente is best kept as a monorepo. But it wasn't one to start
with, due to various historical factors in how the product evolved. What was a
hardware device transitioned into software. The server component was closed
source until we had the bandwidth to get it audited. Weekend projects like Auth
outgrew their reach. Etc.
Let us rewind the tape back to, say, 2 years ago (just to pick a roughly
symmetrical split). While we have grown since then in all product aspects
including number of developers, we are extremely cautious in adding engineering
headcount, so the number of developers hasn't grown that much. Thus it is a
similar number of developers working on the same number of products (Ente
Photos, Ente Auth) multiplied by the same number of platforms (mobile, web,
desktop, server, CLI).
2 years ago, these codebases were spread across a dozen or so repositories.
In February we decided to take time out to finish the task for open sourcing the
server side. This was a natural point to also rein in the proliferation of
codebases, and we took this as a chance to move to a monorepo.
So, as a similar sized team doing similar work, we've experienced an ~year with
a split microrepo setup, and an ~year with the alternative combined monorepo
setup.
Summary
If I had to summarize the difference: Moving to a monorepo didn't change much,
and what minor changes it made have been positive.
This is not coming as a surprise to us. Most of us didn't care strongly about
our repository organization, and overall we weren't expecting much from changing
it either. The general vibe was a monorepo might be better, and so why not, and
since none of us opposed the choice, we went ahead, but we weren't trying to
"solve" anything by the change. We were already happy with our development
velocity.
And indeed, overall it hasn't changed much. We're still happy with our
development velocity, so it did not get in our way. There have been many small
wins however, so for the rest of this post I'll delve deeper into them.
Less grunt work
This is the biggest practical win. There is much less grunt work we have to do.
As an example, take the following pull request. It changed the ML model that is
used for computing on-device face embeddings.
This change affected (1) the photos mobile app, (2) the photos desktop app, (3)
the photos web app, and (4) the ML scaffolding code itself.
In the previous, separate repository world, this would've been four separate
pull requests in four separate repositories, and with comments linking them
together for posterity.
Now, it is a single one. Easy to review, easy to merge, easy to revert.
Less submodules
Submodules are an irritating solution to a real problem. The problem is real, so
a solution is welcome, and submodules are indeed an apppropriate solution, but
they're irritating nonetheless.
All this is to say, we appreciate the existence of git submodules as a way to
solve practical code organization problems, but we wish we didn't need to use
them.
Monorepos reduce the number of places where a submodule would otherwise be
required, and is thus a win.
As an example, previously the web and desktop codebases for the Ente Photos app
had a submodule relationship. This required a PR dance each time a release had
to be made or some other important change pushed to main. All that's gone now.
These two interdependent pieces of code now directly refer to each other, and
changes can be made to them atomically in the same commit.
More stars
This is the biggest marketing win. Previously our stars were spread out across
the dozen or so repositories. If each had a thousand stars, we'd still have 12k
stars in total, but because of the way both human psychology and GitHub's
recommendation algorithms work, it'd come off as less impactful than a single
repository with 12k stars.
Easy
One of the concerns we had going into this was that this might impact our
development velocity. We thought we'll have to invent various schemes and
conventions to avoid stepping on each other's toes.
Those concerns turned out to be unfounded. We didn't invent anything, waiting to
see if the need arose, and it never did. So for an individual engineer in their
day to day work, the move has been easy since we didn't ask anyone in the team
to change their workflows in any way.
There still are no "repository wide" guidelines, except two:
There should not be any repository wide guidelines
Don't touch the root folder
That's it. Within each folder, or subteam of ourselves, we are otherwise free to
come up with whatever organization or coding conventions or what not.
I do realize that maybe the ease for us was a function of both the relatively
small size of our team, and the amount of trust we have in each others'
competence, and both these factors might not be replicable in other teams.
Long term refactoring
Refactoring across repository boundaries requires much more activation energy as
compared to spotting and performing gradual refactorings across folder
boundaries. Technically it is the same, but the psychological barriers are
different.
As an example, we've already merged together many of our disparate web apps into
a similar setup, without needing to make elaborate upfront plans. It happened
easily and naturally, since we could see all of them "next to each other" and
the opportunities for code reuse become obviously apparent.
Connectedness
This way of "working in a shared space without working in the same folder" has
lead to us feeling more connected to each other's work as compared to when,
individually or as subteams, we were all committing to separate repositories.
Previously, it was easy to get lost in one's work (in a good way), but sometimes
it lead to the feeling of working on a small part without being able to see the
whole (in a not so good way).
Now, one can still remain lost in one's own work in the universe of one's own
"folder", so that part of the goodness remains. But there are now also
additional subtle cues that let us see how what we are doing is part of a
interconnected whole. So it's a win win.
What I described might be too abstract, so let me give an example. Everytime I
do a git pull, I get to see all the changes that my team mates have been
working on. The names of the recently changed files. The number of changes in
them. The names of the recent branches. The tags that were recently pushed. All
of these individually are very low bit, and imprecise, information vectors, and
I don't even consciously look at them.
But what I've found over time that, subconsciously and automatically, these
"environmental cues" give me a great sense of "all that is happening around".
What features are being worked on, what stage of completion they are at, what
bugfixes were pushed, what releases were recently made.
Similar serendipitious information exchange happens when I, say, open the pull
requests page and without even intending to, I glance at the stuff others are up
to.
The best part is, all of this is subverbal and effortless. Everybody just does
their thing, and just by virtue of doing them all in the same shared digital
space, arises a sense of awareness and connectedness.
Wrapping up
This is already too long, much longer than I intended to write, so let me stop
now.
I could offer tips, but I don't think there is any secret technical sauce that
is needed. One thing that had bothered me before the move was how will we manage
our GitHub workflows, but that turned out to be trivial since we can scope
GitHub workflows to only run on changes to a specific folder.
An engineering-mindset retrospective document would be incomplete without both a
Pros and Cons section, but we haven't really found any cons that have effected
us so far, so excuse that exclusion.
On a personal level, what I've liked most about the move to our monorepo is the
feeling of being part of a juggernaut that is relentlessly rising towards
perfection, and has attained an unstoppable momentum. The code I'm writing is
not an isolated web component or a goroutine or a little documentation fix, it
is now part of this singular platform that will outlive me.
We are now here to showcase v4.0, that comes with some major improvements.
Changelog
Here are the highlights of what has been added since v3.0.
Sharing
You can now easily share specific codes with your team, with temporary links
that are end-to-end encrypted.
These links will be valid only for the duration that you've chosen. Ente will
pre-compute the codes for this duration, and share those within the link,
end-to-end encrypted.
Your 2FA secret / seed phrase is not shared, and remains secure on your device.
Notes
Auth now supports notes within codes.
You can attach any text (upto a maximum of 500 characters), to provide more
information about your accounts.
These items will be moved to a separate section within the app, under the
"Trash" header.
You can recover codes from here, in case of accidental deletions, or delete them
permanently.
App lock
You can now further protect your codes with a custom lock screen that supports
PINs and passwords. So you can protect your co with either of these, instead of
your device lock screen.
CLI
Starting this release, Ente's CLI will support accessing your data on Auth.
This means you can go ahead and script a workflow that works for you. You can
find more information on using our CLI to export your data from auth
here.
Flatpak
Last but not the least, Auth is now officially available on
Flathub!
Ente has been accepted into the Mozilla
Builders accelerator program!
We're excited for this opportunity to work with some of the best minds that have
shaped our internet.
As a part of this program, Ente will receive $100,000 in non-dilutive funding.
Mozilla Builders
Earlier this month, Mozilla invited us to an event in New York, where we had the
chance to meet the Builders team. Everyone was smart, kind, and incredibly
supportive.
The Builders accelerator was launched by
Mozilla to
promote independent AI and machine learning. The theme for 2024 is Local AI - AI
that runs locally on your devices.
Ente
At Ente, we use Local AI to deliver features like face recognition and magic
search, while respecting the privacy of your photos.
We'll now join a cohort of
builders pushing technology
forward for an AI that is light, private and accessible.
Together
Over the next few months, we'll work closely with the Builders team to
accelerate Ente's growth and development.
We believe this is an important milestone in Ente's journey. There is much we
can learn from Mozilla about building an open source, consumer tech company with
positive impact.
We'd like to thank Monica, Liv, John, Stephen, and the rest of the Mozilla team
for this opportunity. We look forward to building together.
Login
