>Group encryption: [...]<p>Came here to ask just about that but I see it's on your roadmap already, that's good and godspeed with that since encryption is <i>hard</i>.<p>During my PhD, I worked a little while with threshold encryption schemes (sometimes called horcrux encryption schemes, i.e. make n keys, you need at least m of them to perform some operations) (ref. my noob-ish question here ha <a href="https://crypto.stackexchange.com/questions/74763/is-there-an-algorithm-that-allows-to-distribute-elements-securely-between-partie" rel="nofollow">https://crypto.stackexchange.com/questions/74763/is-there-an...</a>).<p>I created a small system that allowed one to reconstruct parametric data from 3D shapes, but if and only if you had at least n pieces of the whole model, because reasons.<p>Reading this announcement, I recalled several things that came up during my research, which apply to this context as well.<p>* How can one make sure that losing one key is not the end of the db (i.e. backup keys)?<p>* How to share db access but not individual keys? (i.e. one key per user BUT all of them can read)<p>* What if encryption is shared by n users but one of them loses their key?<p>* How many keys for encrypting (or just one?), how many of them for decrypting?<p>* Represent all of this in some sort of stateful model, after all it's a db (in my case it was files), it's meant to be cold storage, everything should to be able to be reconstructed/recovered from there.<p>The list goes on and on ...<p>Anyway, just wanted to say that this is a very interesting and promising feature to be found <i>in a database</i>. Great work, I'm eagerly waiting to get my hands on this.