Ente Release Notes

Library sharing

Until now, sharing with family required sharing albums one at a time. Every new trip, and every new album, you had to deal with another round of "did you add me?".

You can now share your entire library with a family member. Head to Settings → Family, pick a member, and tap Share albums. Everything you have is shared, and every album you create from here on is shared automatically.

Hidden albums stay hidden, because some things are yours alone :)

Album slideshows

Pick one album, or a few, and play them as a slideshow. You can set how long each photo stays, the order they play in, and what the background looks like.

We built this because our Discord community asked for it, and it made a lot of sense. The use case I'm personally most excited about is upcycling old hardware. If you have a tablet gathering dust in a drawer, it can now be a photo frame. Pair that with smart albums, and it becomes a frame at your parents' place that updates itself.

Music in Memories

Memories can now play with music, and you can control the audio while they play.

In typical Ente fashion, we wanted to pour our heart into this, so we composed all the tracks for this feature. You can listen to them @ music.ente.com.

Album improvements

Albums can now have descriptions, so you can attach the stories around your photos. These descriptions will show up in your shared links as well.

The Ente filter now shows all your albums on Ente, including the ones shared with you. Also, these filters are easier to reach, and the page will remember where you left off.

Backup improvements

Our backup status now shows progress per file, so you've more visibility into what's happening during large uploads.

On iPhone, a new Backup Mode keeps Ente Photos awake with a dimmed screen while a large backup finishes. iOS is aggressive about suspending apps, and this is now the most reliable way to get a large first backup to complete overnight.

Also, large multipart uploads are now more robust and use less memory.

Faster machine learning

All the machine learning in Ente Photos runs on your device, so every millisecond we shave off matters.

Here is a short summary of the improvements we have landed over the last few weeks

• Inference on recent iOS devices is ~10x faster: ~40ms per image across all indexing models
• Inference on Android is ~4-5x faster, depending on the device
• Pre- and post-processing now runs in Rust, at ~5ms per image on iOS and ~50ms on Android
• HEIC decoding is ~2x faster
• Model load times on iOS are down ~10x
• Indexing runs more reliably in the background, with isolation for foreground and background processes

Here's a longer post outlining all that has changed.

Location search

You can now search for places. City matching is significantly better and country names work in your language as well as the country's native language.

These improvements around your places feeds into Memories, so the ones curated around locations get better too.

We've also reordered results, so what you're looking for sits closer to the top.

Device trash on Android

Ente Photos is now integrated with the device trash on Android. So device photos you delete through Ente Photos move to the device trash and you can recover them through the app.

This is part of the deeper Android gallery integration we are working towards.

Desktop

Desktop has been catching up too.

The biggest change is under the hood. Desktop now runs the same Rust machine learning code as mobile, with CoreML on macOS and WebGPU on Linux and Windows. One indexing pipeline across every platform means fewer bugs, and every speedup lands everywhere at once.

There’s a fresh welcome, too: a new onboarding flow with updated visuals ✨

There's more! The Albums view has been revamped, with filters for quick links, received albums, and shared albums, plus an option to delete all your empty albums in one go. You can edit album names, descriptions, and cover photos from a single dialog, and descriptions now appear in the gallery. Hidden albums have received some attention too: you can add photos and move them between hidden albums, and we’ve fixed their quick link visibility. Also, on Windows and Linux, title bars now follow your selected theme.

There are a few more everyday improvements as well:

• Search while assigning names to people.
• Find photos that have no location.
• Share and apply referral codes.
• Track video processing progress with a percentage under Streamable videos in Preferences.

More

Thank you for scrolling this far, there is a bit more.

• Faster on big libraries, with quicker search, smart memories, map, and timeline scrolling. Android loads large on-device libraries faster and with less memory.
• Device photos show up sooner, with fewer unnecessary reloads after local changes.
• Better video playback, with double-tap to seek five seconds, playback speed controls, and reliable exports when audio and video lengths differ.
• Edits that preserve the original, keeping EXIF metadata, and saving JPEG rotations and flips without recompression.
• Smart albums now pick up newly recognized people automatically.
• A cleaner photo viewer, with tidier controls and captions, and double-tap zoom that follows where you tapped.
• Multiple bug fixes on Android, including optimizations to Free up space.
• Easier support, with the support email visible and easy to access while reporting an issue.

The full changelog has everything.

What's next

For the next sprint, we're focusing on performance and quality of life. We want Ente Photos to be the best photos app, and the best way to get there is by listening to you. So check out the app, find what's missing, and talk to us!

How it works

“Can I share my whole library with my partner?” has been one of the most frequent questions we get. Google Photos has Partner Sharing. Apple has iCloud Shared Photo Library. Both are convenient, but neither is end-to-end encrypted by default. Our users have asked for the same convenience without giving up that guarantee.

Until now, the closest you could get in Ente was selecting multiple albums and sharing them in one batch. It worked, but it was still manual, and it wouldn't include albums you created later.

Today we're introducing Library Sharing: share all the albums you own with a family member in one go, and optionally keep sharing new albums automatically as you create them. All of it end-to-end encrypted, like everything else in Ente.

Head to Settings → Family, pick a family member, and tap Share albums.

From there you can:

• Share everything at once. Select all the albums you own (or just some) and share them in a single action.
• Choose what they can do. Assign Viewer, Collaborator, or Admin per album, or use one default role across your selection.
• Turn on automatic sharing. Enable Library Sharing for a family member, and every album you create in the future is shared with them automatically. No more "oh, I forgot to share the trip album."

Your family member sees the albums appear as shared albums in their app, and new photos you add show up for them as your photos back up. This is the same live sharing Ente albums have always had.

Sharing everything, without oversharing

A feature that shares everything needs to be careful about what "everything" means. Library Sharing is built to respect your intent:

• Hidden albums are skipped. Albums that are hidden when Library Sharing runs are excluded from automatic sharing.
• Your removals are remembered. If you stop sharing an album, or your family member leaves it, automatic sharing won't quietly add it back. This is enforced by the server, not just by your app.
• You stay in control. You can stop sharing any album at any time, change roles later, or disable automatic sharing entirely. Disabling it keeps your existing shares intact; it just stops new albums from being added.

Tidy up, together

Sharing your library is also a way to share the work of keeping it in shape. The roles you assign decide how much your family can pitch in:

• Collaborators can add. Both sides of the family can land their photos in the same albums.
• Admins can help clean up. Make your partner an Admin, and they can remove photos from albums and suggest deletions for the duplicates and blurry shots. Suggestions land in your review queue, and nothing is deleted until you approve it.
• Everyone can react. Shared albums support comments and likes, end-to-end encrypted with the album, so the conversation about a photo lives with the photo.

Same encryption, more convenience

Convenience features often weaken end-to-end encryption. Library Sharing does not.

Every album in Ente is encrypted with its own key. When you share your library, your device seals each album's key to your family member's public key and sends the sealed keys, along with the metadata needed to establish each share, to our servers in batches. Our servers can establish the shares but cannot decrypt the album keys or your photos. Only your family member's devices, which hold their private key, can.

Your Library Sharing preferences are stored as end-to-end encrypted data and synced across your devices. Enable Library Sharing on your phone, and your other devices pick up the preference when they sync.

In short: we added partner sharing without giving Ente access to your photos.

Family first

Library Sharing is launching for family plans. Every paid plan lets you add up to five family members at no extra cost, with storage shared from your plan, which makes families the natural place for whole-library sharing to start. Shared albums don't count twice: each photo counts only against the storage of the person who uploaded it.

We'd love to hear how you use it, and where you'd like it to go next.

Availability

Library Sharing is rolling out now in Ente Photos on iOS and Android. Make sure you're on the latest version. Support on web and desktop is on the way.

And as always, all of this is open source: the client and the server, including everything described above. Self-hosters can use Library Sharing with the latest release of our server.

Ente Photos is an end-to-end encrypted home for your photos. If your family values privacy, give it a try.

Why local speed matters so much to us

Ente Photos now processes your photos up to ten times faster. For the first time, our ML runs on the GPU. And everything around the models is now lean Rust.

On a recent iPhone, running all models together takes only ~40ms per photo, 10x faster than before. Photos already on your device now index in a fraction of the time.

Everything in Ente is end-to-end encrypted. We can't see your photos, so we can't run ML on them for you. Your phone does the work other services do in a data center.

That makes local processing the whole game. Every model we ship has to run over your entire library, on your device, without draining your battery or getting in your way. The faster it runs, the more we can do with it, for you.

Not just a switch

Telling ONNX Runtime (ORT) to use the GPU is a one line change. Getting a fast model out of it is not.

CoreML and WebGPU (the GPU accelerators) only accelerate the model operators they know. The rest goes back to the CPU. A model that bounces between the two is often slower than one that stayed put. So we rewrote our models.

Our face embedding model has 33 PReLU activations. WebGPU has no kernel for them, so each is now two plain ReLUs: Relu(x) - alpha * Relu(-x). Same math, but now it doesn't bounce between the GPU and CPU.

Our CLIP model had 54 expanded GELU expressions consisting of multiple operators. Each is now one fused Gelu operator that CoreML and WebGPU both understand.

Our face detector had a dynamic batch dimension. It's pinned to one now, so the shape arithmetic folds out of the graph.

Every rewrite is scripted and verified against the original model. Same numbers out, far less work to get them.

The work around the model

Model inference is only part of indexing a photo. Before the model, the photo has to be decoded, resized and turned into a tensor. After inference, raw outputs have to become faces, boxes and embeddings. All of that runs in Rust, and most of our optimizations went there.

Our HEIC decoder got a round of speed work. HEIC, the iPhone default, now decodes twice as fast.

As for preprocessing, we made sure a decoded photo lives in one buffer for the whole pipeline, across models. Every stage borrows it, nothing copies it. Faces are aligned straight out of the decoded pixels, and any resize only touched the pixels that actually need to go into a model. Resize buffers are allocated once and reused. It's these small choices made everywhere that add up.

Postprocessing follows the same principle. Model outputs are read straight from ONNX Runtime's memory, in whatever precision the GPU returned them. We allocate only for what we keep.

Pre- and post-processing now take a few milliseconds per photo on iOS. Negligible even compared to the improved model inference.

One pipeline, every platform

This is the payoff of our Rust rewrite, which started with a vector database and now covers our cryptography too. It's far from done, but it's already paying off.

Rust compiles natively to every platform we ship on. So mobile and desktop now run the exact same ML code. Desktop moved over a week after mobile, with the GPU enabled on macOS, Windows and Linux.

As the rewrite continues, more of Ente will work this way. Feature parity by construction, and faster product development everywhere.

Tests, tests, tests

The other enabler is less glamorous, but crucial: tests. Lots of them.

ML indexing used to be one of the scariest parts of our codebase, right after upload and encryption. Not because it was slow, but because bugs here are silent. A subtle preprocessing mistake produces embeddings that look fine, even when they're not. They get stored, synced, and quietly make search worse. So every change used to come with extensive manual testing.

That's fixed. Every pull request now checks our Rust ML code against ground truth from the original Python models. Shipping something that breaks indexing is now close to impossible.

The safety net extends to your phone too. GPU drivers in rare occasions can return plausible-looking garbage while reporting success. So on every model load, the app runs a verification inference and compares it with the expected output. If the GPU is off, we fall back to the CPU.

With these tests in place, we could optimize as aggressively as we wanted. Every optimization was automatically verified before it shipped.

Full steam ahead

Local processing has gone from something to be careful around to something we can build on. Analyzing what's on your device is fast, verified and identical across platforms.

The Rust rewrite continues, and there's more on the way. The code is on GitHub. What we build on top of this is partly up to you. Come tell us on Discord what you'd want first.

Let’s be honest - AI in photo apps isn’t an imposition.

In fact, if anything, it just works. It’s almost magical to be searching for a specific picture of your dog, mid-air, on a beach, from a decade ago, and find it immediately by just typing ‘dog jumping beach’. People have wanted this for years, and now that it is finally here, nobody is going back. Every photo app will have it, Ente Photos included.

But the thing to consider is a narrower question - what does the software actually have to know about you for that search to happen, and where does that knowing happen?

Your photos are obviously full of data.

What you looked like over the years, your relationships, your kids, what your house looks like, what car you drive, where you went for holidays, the friends who turn up on your birthday, the friends who stopped showing up a few years back, and a million other things. Nobody consciously registers all of this as data, but its data nonetheless, and as soon as an AI agent has access to all of this it can start processing them into information, by labelling faces, creating timelines, and modelling relationships and behaviours.

Google Photos is undeniably great at this.

Their Ask Photos feature can draw on user-inputted face groups, names and relationships, location, and situational context from the contents of the picture themselves to answer as random a question as ‘What kind of cake did I have on my birthday 4 years back?’ All it needs is that your photos are backed up on Google’s servers, because the model doing the work exists on their servers.

And herein lies the trade-off.

The question you type may be reviewed by Google staff to improve their features, Ask Photos keeps a list of things it’s learned about you from your questions, feedback you give is stored in Photos Activity, and continued background refinement means that your data keeps getting worked on even when you’ve closed the app. None of this is inherently malicious. It is what server-side AI is. If you want personalized insights, generative editing, and contextual responses, the AI model obviously needs more intimate access to your life and, in some cases, human review to ensure quality and accuracy.

But there is another way.

Ente Photos has AI Search too. It includes face recognition. It includes semantic search. It includes object recognition. It includes location-based search. It includes date-time based search. It includes text recognition. It includes people grouping. It can find you the picture of the dog jumping mid-air on a beach from a decade ago. But what it cannot do is tell you what kind of cake you had on your birthday 4 years back. Because that needs a model that can reason across faces, text, and context at once, and that model can currently only exist on a server. The AI for Ente Photos exists only on your phone.

Ente's servers never see your pictures.

Ente’s servers don’t even see your queries, the results, or your feedback; nothing gets refined in the background because there’s no reviewer, and there is literally nothing to review. It’s how Ente Photos is built. That is why we cannot deliver the exact AI Search experience that Google Photos can. Because the gap between us is exactly the extra amount of yourself that you’d have to hand over. And we are not comfortable with that.

You might be. And that’s fine. We just think there should be an option for people who'd rather keep their life on their own phone instead of a company’s server, even if it means that the AI does a tiny bit less.

Whether that trade-off is worth it is up to you.

This started as a small internal itch. I needed a QR code for some merch we were printing. A simple thing. Paste a link, get a QR code, print it, move on with my day.

It wasn't simple.

Every QR site I opened wanted something from me first. Sign in. Accept cookies. Close this popup. Look at this ad. And after all of that, the QR code it finally gave me looked nothing like our design. Wrong colors, ugly corners, sometimes a watermark sitting right on it. So I would download it anyway, open it in an editor, and fix it by hand, every time.

Adobe has a nice one. But it also wants a sign in, and the good parts are paid. I didn't want an account. I wanted a QR code.

The bigger problem is tracking

Most free QR generators don't put your link inside the QR code. They put their link. Someone scans your poster, it first goes to their server, and then it redirects to your page. A random company sits between you and every person who scans your QR, counting the scans, watching where they come from. And if that company folds or decides free was a mistake, every QR you ever printed dies.

So we built our own

I work at Ente, where we make beautiful privacy apps for everyday use. So building this one was an obvious thing to do.

ente qr is the simple thing I wanted that day. You paste your link. The QR code appears. You download it. Done. Everything happens in your browser. Your link goes straight into the code. No account, no cookie banner, no ads, no backlinks, nothing stored anywhere.

And because I care about how things look, the QR codes had to be beautiful. Rounded modules, colors that are yours, your logo in the middle, frames with your own words on them. If you care about the thing you are making, the QR code on it should not be the ugly part.

Print it on your merch. Stick it on your store counter. Put it on a poster, a menu, a business card, a wedding invite. Or hit share and it becomes a little story card you can post anywhere. It's yours, forever.

The love part

I spent far too long on the small potato stuff. The card on the homepage turns to face your cursor, and a sticker stays wherever you drop it. It's over-animated and I like it that way.

Go make one @ qr.ente.com

It's free. Make one for whatever you're working on. I hope it saves you the twenty minutes it used to cost me.

We've deployed our first post-quantum crypto change on cast.ente.com. This vets all the moving parts in Ente's transition to quantum-secure cryptography, so now what remains is over time moving the rest of the PQ-affected flows to quantum security.

In the rest of the post, I'll give a brief background of the what and why, explain what we've done, and then outline how it'll tie to the rest of our PQ journey.

Ente uses cryptography to guarantee that no one, not even Ente, can see your photos and read your documents.

Quantum computers, when they become a reality in the future, will have ways of breaking the security of many of the standard cryptography algorithms.

The bulk of the encryption algorithms we use are already safe even in the presence of quantum computers. The main workhorses: the algorithms (the so-called symmetric-key methods) that Ente uses to encrypt your photos and files and auth codes, all of them have no known weaknesses.

However, a small but important subset of the algorithms (the so-called asymmetric-key methods) that allow Ente users to share photos with other Ente users are not quantum safe.

So the task for us is to migrate these asymmetric-key algorithms to new replacements that are ready for a post-quantum universe. These are affectionately known as PQ algorithms.

As I mentioned, the bulk of the encryption we use doesn't need changing. The places where sharing happens are the places that need changing.

But Ente allows things to be shared in a lot of ways! Some of them might not be obvious to a user, but behind the scenes a share-like mechanism is happening.

Case in point is our support for playing your albums on your TV, other cast-enabled devices, and even pairing to a web browser using a PIN. This is done by our "cast" web app, cast.ente.com.

Behind the scenes, this relies on an ephemeral share between the cast web or Apple TV app and your Ente Photos app to ensure that your photos remain end-to-end encrypted. And since a share is involved, we need to use an asymmetric-key algorithm. And these, as we discussed, are not quantum safe.

Since the share is ephemeral, this is both a realistic and a relatively easy flow for us to migrate (since there are no long term shares that need to be re-encrypted). Because of these properties, we chose to use cast as our first step in the post-quantum universe.

The cast app now uses an X25519 + ML-KEM/Kyber exchange, the same recipe that Signal and TLS use for their post-quantum asymmetric key exchanges.

In brief, the new PQ algorithm negotiates two keys: one with the classical method (X25519) and one with the quantum-safe method (ML-KEM-768). Think of it as putting two locks on your box. In the case that there is a quantum computer which can break the classical method, the quantum-safe lock still holds. However, the classical method is battle tested over decades, so in case the relatively new quantum-safe method has a (classical) weakness, the old lock still holds strong.

This change was done fully in Rust! All of the cryptography and the logic for handling the dual key dispatch is taken care of by the same Rust code, and all the Ente Photos apps (mobile, web, desktop) use the same piece of code instead of implementing it again and again.

In fact, while there is a bit of wiring to get this all to work, the core functionality is small enough that I can show it to you here:

fn open_payload(&self, encrypted_payload: &str) -> Result<CastPayload> {
let ciphertext = b64::decode(encrypted_payload)?;
let plaintext = hpke::open(&ciphertext, &self.pq_secret_key, HPKE_INFO).or_else(|_| {
crypto::sealed::open(&ciphertext, &self.secret_key.public_key(), &self.secret_key)
})?;
Ok(serde_json::from_slice(&plaintext)?)
}
fn seal_payload(
public_key: &str,
pq_public_key: Option<&str>,
payload: &CastPayload,
) -> Result<String> {
let plaintext = serde_json::to_vec(payload)?;
let ciphertext = if let Some(pq_public_key) = pq_public_key {
let public_key = hpke::PublicKey::try_from_slice(&b64::decode(pq_public_key)?)?;
hpke::seal(&plaintext, &public_key, HPKE_INFO)?
} else {
let public_key = PublicKey::try_from_slice(&b64::decode(public_key)?)?;
crypto::sealed::seal(&plaintext, &public_key)?
};
Ok(b64::encode(&ciphertext))
}

(The full code, as usual, is available on our GitHub. Open source ftw!)

The main trickiness comes from handling graceful migration. Reminder that Ente is eminently self-hostable, and we try hard to make sure that self-hosters have a hands-free first-class experience too.

So while we could do a more involved dance to roll this out on our production infrastructure in some orchestrated way, that would've still required self-hosters to also tap along.

Instead, we've arranged things such that all of the flows remain backward compatible. There are three separate moving parts: the cast app (that runs on the TV), the server (that coordinates the pairing), and the Ente Photos app (the mobile/desktop/web app that the user is using to cast their photos). And they can be updated in any order!

For example, if a self-hoster has the latest cast app and the latest server, but still the old client, things will continue to work. Eventually, all three of them will just get naturally updated, and they will be able to recognize each other and agree to the use of the new PQ flow.

The cast app is the first but important checkpoint for us. It vets out the algorithms and the pipeline. Now we will proceed with the longer and more involved task of going through all of the remaining share flows and bringing them along to the post-quantum universe. The symmetric core (the actual photo encryption) is already quantum resistant, so once we're done with the share flows your favorite photo sharing app will be ready for whatever quantum computing brings. See you on the other side :)

Interact with memories

I got back into product design at Ente after a while, and the last few weeks have been a blast.
Our latest release includes a lot of improvements - big and small - many of which I've personally been looking forward to for a while.

Our pursuit of building the best photos app has pushed us to understand how to curate memories we're grateful for.
While solo trips invoke a certain sense of gratitude for existence, there is more depth to the moments that were shared with someone else. Regardless of how picture im-perfect these moments were, glimpses to shared existence are more grounding.
To help leverage this understanding, we have added the ability to comment, react and kick start a conversation on shared memories. This brings your memory back into the feed of everyone you've shared them with.

Share memories

Not everyone is on Ente, unfortunately.
So we've made it easier to select and share specific memories from the sets we curate. We've also polished the view that's presented to your friends when they view your memories.
This is one of my favorite layouts for shared links we've built so far. If you have more ideas on how we could present your photos, let us know!

Save contacts

I had spoken about setting avatars for contacts a while ago.
We've now made it much easier to connect faces with your contacts, so you no longer have to look at email addresses and dummy avatars.

New photo viewer

We've also revamped our photo viewer and the information sheet attached to it.
It's surprisingly difficult to present all the information connected to a photo (names, timestamps, locations, albums, people, ...) without overwhelming the interface, and we're happy with what we've crafted.

Import improvements

We've revamped the upload experience on Desktop to make the process more reliable and easier to understand.
We've also simplified importing from Google Photos - supporting favorites and partner shared items, so they reflect on Ente Photos as well.

More

Of course there's more!

Faster photo loading, with smarter cache management that consumes less space on your device.
Improved OCR, with a more reliable interaction (just long-press to select).
Nicer dummy avatar colors, although you really should consider connecting their faces now!
More reliable background sync, with fixes for crashes in the background, apologies to those who were facing them.
New changelog screen, that sparks joy!
Polished desktop experience, with improvements to the machine learning pipeline and rendering of archived albums, file-info panel, shared file actions, add person screen, toasts and more.

What's next

It was nice to write this post, thanks to the wonderful product work from the small team at Ente, who are already working on the next set of improvements.
We're tightening the system integration on Android, speeding up on-device machine learning, pushing towards feature parity on desktop, improving sharing with family members and designing ways to help you clean up your library - in a fun way! More on that in a few weeks.
If you'd like to influence our product roadmap or get early updates on the new spaces we're venturing into, join our community.

I recently created a Paste link with a secret key that I meant to send to my personal chat.
And in a hurry, I accidentally dropped it into one of my group chats.
Even though I quickly deleted it for everyone, it left me with a valid concern:
Someone could have opened it before me.
And if that had happened, there would have been no way to know who.
The only way we could think of preventing this was was to add a password to paste.
That way, only someone with the password can open it.
And guess what? We shipped it. Now you have a more secure paste.

But here's the thing - in the first place, I was trying to open the Paste link
from my desktop on my mobile. That's why I tried sharing the link.
If there had been a better way to do this, the whole situation could have been avoided.
Turns out, it was already there.
I could have created a QR code. I just missed it because it wasn't obvious
enough.
So we fixed that too with this update. 😉

Try it at paste.ente.com.
And if you want to explore a bit more about how it works, we now have a
dedicated Paste documentation as well:
ente.com/help/paste.

In March, we released Ensu more as an idea than a product. A private, on-device LLM app, shipped early on purpose — so the people who would care about something like this could shape what it becomes.

Then we paused.

We wanted to see whether there was real interest in a privacy-first AI app made in a user-friendly way, and what people would actually ask for once they had it in their hands. Lots of feedback, bug reports, and "have you considered..." messages later, two things stood out:

People find value in a private AI app.

And there is still so much room for improvement!

So we're picking the work back up. This release is the start of that.

Gemma 4 by default

On desktop, Ensu now ships with Gemma 4 out of the box. You get noticeably stronger answers from the very first chat, with nothing to configure and no separate download to wait for.

Talk to Ensu

On Android and iOS, you can now tap the mic and speak your prompt instead of typing. Transcription happens locally on your phone, so your voice never leaves the device.

Image queries, way faster

Asking Ensu about a picture used to take a noticeable beat. A round of work under the hood has brought that down to close to instant, across every platform.

Smoother model downloads

Pulling a new model onto your device — desktop or mobile — is dramatically quicker and far more reliable than before. Less waiting, fewer restarts.

This is the first of more iterations to come. We're excited to see where they take us, and the direction will be shaped as much by you as by us. If there's something you wish Ensu did differently, a feature you'd love to see, or a use case we haven't thought of yet, come tell us in the #ensu channel on our Discord.

You can download Ensu here.

Ente Locker is for the practical parts of a life: IDs, insurance papers, medical records, passwords, notes, and the documents someone may need in your absence.

Since launch, we learned that someone, without an Ente account, also needs a way to recover your Ente account if you lose access, are incapacitated, or are no longer around.

That is what Legacy Kit is for.

How it works

Legacy Kit is a set of 3 recovery sheets. Each sheet has a secret QR code and instructions to recover your account. You give each sheet a name ("Son", "Lawyer", "that drawer with all the cables", ...), print or save, and share them separately.

Any 2 of the 3 sheets are enough to recover your account. One sheet on its own is not enough.

The person recovering does not need an Ente account or app. They can open legacy.ente.com and scan 2 of the 3 sheets to access your full Ente account – Photos, Locker and Auth.

Waiting period

Each kit has a configurable waiting period: immediate, 1 day, 7 days, 15 days, or 30 days.

Immediate is useful for self-recovery, in case you have locked yourself out of your account. Longer waits are better when the kit is for someone else, because they give you time to notice and block an attempt if something looks wrong.

You can create up to 5 kits per account. This lets you plan for different situations. A short-window helps with self-recovery, and a longer one with inheritance.

Revoking access

When there is an attempt to recover your account, Ente emails you.

You can block an active recovery session within the waiting period you configured.

You can also delete a kit to disable those sheets and prevent any future recovery attempt.

More details

Legacy Kit started as a hackathon project called 2of3. The prototype split a secret into 3 parts. It evolved into Legacy Kit after we made it revocable and server-mediated.

When you create a Legacy Kit, Ente generates a random secret and splits it into 3 shares using the 2-of-3 threshold scheme. Any 2 shares can rebuild the secret. Here is the maths.

This secret never touches our servers. From it, Ente derives an encryption key that protects your recovery material, and a challenge keypair that lets the server verify someone has enough sheets without seeing the secret.

During recovery, a helper combines two sheets in their browser to open a sealed challenge from the server. After the waiting period passes, the server returns the encrypted recovery material, which is decrypted locally to complete a standard password reset.

The server never sees the kit secret, the shares, or your decrypted recovery key.

Legacy Kit is now available on Ente Locker on both Android and iOS.

Pick photos from Ente in other apps

We've been steadily working on making Ente Photos a great gallery app on Android, one that fits naturally into the everyday moments where you reach for your photos: tapping a camera thumbnail to review a shot, attaching a photo in a messenger, browsing your library without thinking about which app you're in. The latest release is another solid step in that direction.

When another app asks you to attach a photo or video, Ente Photos now shows up as one of the apps you can pick from. Open it, browse your library, select what you need, and the original app gets the files back. It works with the system photo picker and with any app that uses the standard Android intents for media.

Open camera shots directly in Ente

After taking a photo, many camera apps show a small thumbnail you can tap to review the shot. On supported camera apps, that thumbnail now opens the photo directly in Ente's viewer — zoom, share, or delete it without leaving Ente.

For details and known limitations (looking at you, Pixel Camera), see the docs.

After Gallery mode let you use Ente Photos without an account, these integrations are the next step in a longer effort toward Ente Photos working as a true Android default gallery — something we're tracking in this discussion. More pieces are already on the way. If there's a gallery flow you rely on that still feels rough on Android, come tell us in Discord.

When we launched Locker, we wanted it to be a private place for important information.

The kind you may not open every day, but need quickly when the moment comes.

Medical records. Identity cards. Insurance papers. Travel documents. Notes and passwords your family may depend on.

We have been improving Locker around that simple idea.

Your files should be available when you need them. They should be easy to share with the right person. And they should be easier to manage when you are at a computer.

Here's what's new.

Save files for offline use

Some documents cannot wait for a good internet connection.

You can now save files in Locker for offline use on mobile. So when you are travelling, at a hospital, or somewhere with poor network, your selected files can still be opened.

Saved files stay encrypted inside Locker on your phone, so you can keep important documents close without leaving them exposed.

Share collections with links

Once your documents are organized in Locker, there are times when someone else needs access too.

You can now share a whole Locker collection with a link. This is useful for travel papers, medical files, property documents, or any group of files that belong together.

The person opening the link does not need an Ente account. They can open it in their browser and view what you shared.

You can also add a password, set an expiry, and limit how many devices can open the link.

Try Locker on web

Locker is also now available on web in beta, at

locker.ente.com.

This gives you more room to review, organize, and download documents from a computer. It is helpful when you are sorting through many files or sharing a collection with someone else.

Shared collection links also open on web, including password-protected links.

Mobile keeps Locker with you. Web makes it easier to sit down and manage what matters.

Still private by design

Locker remains end-to-end encrypted.

Your files are encrypted before they leave your device. We cannot read your documents, notes, or passwords.

Offline files, collection links, and web beta all build on the same promise: a private place for the information that matters, available when you need it.

If you have not tried Locker yet, now is a good time to start.

Memory Lane

A photo takes a second to capture, but what it holds can last a lifetime. Your phone is full of them - birthdays, trips, ordinary Tuesdays that somehow got preserved.

But the tools we use to share photos rarely reflect what those memories are worth. A photo on WhatsApp becomes just another message in a busy chat. A post on Instagram becomes part of a feed, quickly scrolled past.

Neither feels right for a photo of your grandmother from twenty years ago, or your best friend on the last night of a trip you still talk about.

Those photos deserve better.

We built Memory Lane to help show someone how you’ve captured them over the years.

Open a person’s page in Ente, and you’ll see a quiet journey through time, told through the photos you’ve taken of them. A face changing slowly. A child growing up. A friendship measured in a handful of special moments.

It’s one of the most personal things you can share.

Share memories as links

Memories in Ente, whether from an anniversary, a party, or a trip you’d half forgotten, can be shared as a link.

The person on the other end sees exactly what you see: the same photos, the same framing, the same feeling of being taken back.

They don’t need an account. They don’t need the app. They just open the link, and it’s there.

Faster links

For shared memories to feel right, receiving them has to feel effortless. We’ve put a lot of care into making the experience feel as close to the in-app version as possible.

As part of that work, we also refactored our web app to make album links load significantly faster, up to 80% faster.

Sharing is one of the most important parts of a great photos experience. Memory Lane and shared memory links are a step in that direction, but there’s more to come.

We’d love to hear what you think. Find us on Discord.

We recently shipped a new pure Rust cryptography layer that now powers the Locker web app and Ensu. It is the start of a gradual move away from libsodium toward a single shared implementation that compiles natively to mobile and trivially to the web via WASM.

We love libsodium. But in Rust, the popular wrappers still bottleneck on libsodium-sys, a C dependency that makes cross-compilation painful. Pure Rust crates from the RustCrypto project gave us the same primitives with byte-for-byte wire compatibility, and one cargo build for every target. One crate, thin binding layers for each platform: web, mobile, CLI.

The new layer (our ente-core crate) is not large, but since it handles all the encryption we felt we needed independent eyes on it before rolling it out.

The review

Short version: we passed. winfunc found only medium and low severity issues, none of which materially affect us within our threat model. We’ll still address them, but for all practical purposes, green tick.

That's usually where the blog post would end. Link the report. Move on.

But we think the auditor deserves more than a footnote.

winfunc

winfunc is an LLM-powered security audit startup.

Their name is a nod to the CTF idea of a 'win function': a function that already exists in a program for a different purpose, but that an attacker repurposes by reaching it in a context where it should never run.

We'd been through the other, more established automated security review tools before, and had found them to be mostly noise.

We first came across winfunc when they audited our server code on their own initiative. That report was noticeably better: It was clearer (the findings read like they were written for an engineer), had fewer false positives, and felt directly actionable ("here's what's wrong, here's where, here's what to do.")

We met the founders. They're sharp, young, and building something that already punches well above its weight.

And when it came time to review ente-core, we reached out to them.

What's next

ente-core is live in the new Locker web beta, and is also integrated into Ensu.

Over time, unless a pure Rust libsodium port appears, it'll make its way into our other apps too. The engineering holy grail: one pure Rust crypto implementation everywhere.