> I think a full index of the contents of hundreds or thousands of emails and their attachments is soon going to take a lot of space and be slow on a mobile device.

I initially read “hundreds of thousands” and would have agreed that it might be a problem for those rare users (not even sure about that), but no, “hundreds or thousands” is a trivial amount of data. Normal mailbox operations already need to synchronize state; you just apply index operations along with this. (As for indexing PDFs and images, I don’t expect that in a basic implementation, or maybe ever. Doesn’t mean the entire feature should be missing.)

Which is why other services (e.g. Tutanota) have already implemented it, and also manage encrypt things like subject lines, which Protonmail doesn’t (!).

Implementing that is easier said than done.

I'd like to first see a real example of a mail service that in addition to e2e encryption is also best in class in terms of usability (quality and speed of search, spam filtering, auto categorization, ...).

For my use cases, usability comes first and e2e encryption comes second or even third (after price)

> I think a full index of the contents of hundreds or thousands of emails and their attachments is soon going to take a lot of space and be slow on a mobile device.

The index doesn't need the attachments, does it? At a couple kilobytes per message you can fit a whole lot of text into a reasonable amount of phone storage. And there's no reason it should be slow.

> Also if you have multiple clients, which one is going to update the index and how do they sync up?

Each client can either independently index new emails as they come in or upload something like a compressed csv of new entries for the index database. A hundred new emails should only take milliseconds to process.

> if it needs to index pdfs and images.

How do you index images? Indexing pdfs is much more of a nicety than a necessity, and it could be a setting on whether you want to spend the data. It shouldn't take long though, as far as I know. You don't need to render it or anything.

> If multiple mobile clients build their own indices syncing them and merge conflicts might arise.

If they build their own then you don't need to sync.

If they share and do sync, I still don't see how you'd get merge conflicts. Emails don't change, and index updates are just adding and removing entire emails.

I have a lot of emails that are receipts from various businesses where most of the content is in an attached pdf. Same for image where you'd need to run OCR and some off the shelf object recognition on it but that's less common based on my usage.

Building the index independently on each client means if you login from a new device you need to wait for the index to be built. That said, maybe the index can itself be encrypted and uploaded to the server to be downloaded by new clients. Also building index is potentially expensive on a mobile phone and I don't want to wait for my phone to be plugged in to be able to search recent emails. The alternative would be to have an always on computer at home that decrypts, indexes your emails and then your mobile client updates its database from there. This whole system feel so fragile though.

I'm no expert in cryptography or syncing databases but imagine there are a lot of technical and usability issues.

> Building the index independently on each client means if you login from a new device you need to wait for the index to be built. That said, maybe the index can itself be encrypted and uploaded to the server to be downloaded by new clients.

But how often do you log in from a new phone? And yes it could be.

> Also building index is potentially expensive on a mobile phone and I don't want to wait for my phone to be plugged in to be able to search recent emails.

As I said in more detail before, I don't think it is.

> I'm no expert in cryptography or syncing databases but imagine there are a lot of technical and usability issues.

There's a few. But making an app is already a process of dealing with dozens of technical and usability issues. None of these new ones sound like dealbreakers.