This are raw notes, they might not be complete and/or too cryptic.

* mail is base on search
* 3 ways of encidx:
  ** 1- dec as you go in your storage
  ** 2- index the dec message (index is secure)
  ** 3- PIR server side enc queries
* 2 is the only viable
* How to handle the index:
  ** trusted machine
  ** enc container
    *** separated indx for enc mail

* you even if the query is secure, but retrieving the emails the server could guess it
  ** mixed enc search result retrieval leak
  ** all encrypted search result retrieval leak, too
  ** if you have the whole set of emails locally is fixed
  ** it can solve by fetching more than what you want

* index could be big, we can accept it
  ** full text index ~= the size of the mail store
  ** bandwidth is a problem for big syncs

* 3 is expensive in CPU and bandwidth, it can be more leaky to reduce that
  ** in the long term the server could guess the content of the encrypted index by the relations of emails that are retrieved
  ** we could put the encryted emails in the index, it's not doable

* single mail
* lables (tags)
* free search

* For a lot of results I don't need to see them, but the MUA loads them for when you see it

* Each client can build the index, less bandwidth more CPU

* make a bloomfilter for each word, too much computation time

* the 90s technology solves everything (do anything in the client)
  ** does that work in the smartphone?

* usability: unlock the secret keys/storage for the whole session
  ** it index when things are fetched

* We don't need to index encrypted emails, that could be a choice of the user

* clients to think on how to sync and store email storage and index in a secure manor

* the case of separated indx for enc email don't gain much, too hard to explain to the user to choose


== local model
* store everything in the client side
* store the entire message archive
* protect the index
* pruning strategies (index and messages)
* protect archive
* lookaside metadata associated per message, you could store the session key of the message so you can decrypt it if you don't have the key anymore