Is this open to key commitment exploitation? Password derived key? E2EE and MLS thoughts?

Hi,

This is such an incredible repo/example, thank you to all at Dwyl for making this.

I was curious if this is susceptible to key commitment vulnerabilities?

**Paper**: [https://eprint.iacr.org/2020/1456](https://eprint.iacr.org/2020/1456)
**Cryptography.fm podcast episode**: [https://www.cryptography.fm/10](https://www.cryptography.fm/10)

**Password derived keys**
If so, then would it make sense to implement a password derived key mechanism [part1](https://medium.com/@badu_bizzle/per-user-encryption-in-elixir-part-i-645f2dfaf8e6) and [part 2](https://medium.com/@badu_bizzle/per-user-encryption-in-elixir-part-ii-fd984017fb7d) from Badu's Medium posts?

I was thinking that the key/get_key process from AES.encrypt/1 is then pulling the password_derived_key from each person, perhaps making the system administration agnostic to the symmetric keys?

**Asymmetric with sharing**
Or perhaps with asymmetric encryption, similar perhaps to [part 3](https://medium.com/@badu_bizzle/per-user-encryption-in-elixir-iii-6a5760a8a779) and [part 4](https://medium.com/swlh/per-user-encryption-with-elixir-iv-a56a1fbe8d4a) from Badu's Medium posts?

**E2EE with MLS**
I guess at that point we're approaching "end-to-end" encryption in the browser (a dream)? Which, as I understand, we should be waiting for the IETF's Messaging Layer Security architecture/protocol standard to be ready for implementation?

Github MLS repos: [Messaging Layer Security draft documents](https://github.com/mlswg)
Datatracker: [https://datatracker.ietf.org/wg/mls/about/](https://datatracker.ietf.org/wg/mls/about/)

Would love to hear what you think, thank you.

❤❤❤