Replies: 1 comment 1 reply
-
Thanks Simon! I appreciate that! Currently the SQLSync architecture requires re-running mutations on the coordinator. This is how SQLSync provides global ordering and ensures that everything converges into a single consistent view of the data. It's a different set of tradeoffs from using CRDTs and enables different kinds of use cases. To make E2E encryption work with a coordinator model is a bit tricky, but not impossible. I'm currently working on a new replication engine for SQLSync which should make it much easier to do. In the new architecture, replication, backup, and global order will happen outside of the coordinator and can work entirely on encrypted data (it only needs access to metadata). In this new world, the coordinator logic can run on every device. This makes writing mutation handlers a bit more tricky as they need to be completely pure, but in practice this is not too hard to achieve. Upgrades are also a bit harder - but again, not insurmountable. So yea, I think this is 100% doable and something I'm very excited to experiment with. Work on the replication engine is going well, but I can't commit to a specific timeline at this point. Feel free to reach out to me directly through Discord or via email (hello at orbitinghail dot com) if you want to go deeper. |
Beta Was this translation helpful? Give feedback.
-
First of, love your projects - great work and approach. Hope you can keep up the momentum!
Any thoughts or plans on how to enable end-to-end encryption? I think it's a quite common use case that you want to sync the data through a sever/coordinator/relay, but don't want that other party to see your data. Locally the data can be cleartext, but before the CRDTs/mutations are shipped around, they should be encrypted (and decrypted when received, before applying).
Beta Was this translation helpful? Give feedback.
All reactions