I think the encryption change is mostly ready to land. There are surely things we can improve, probably bugs, and likely things that don’t work when confronted with reality, but we’re not going to figure those things out by staring more at the code from a distance. It needs testing in various scenarios and to accomplish that it really needs to be merged and available somehow, so that we can play with it easier.
At the same time I’m not entirely comfortable with calling it done and letting it loose on everyones data right away.
Ideally I’d like some sort of feature flag gating. That is, the encryption feature would only be available if you’re running the nightly, or if you’ve set a specific STEXPERIMENTAL_FEATURES=encryption variable or something like that. We don’t have a framework for doing that kind of thing, and it would anyway be tricky in this case since the change involves a hundred changes to the GUI.
The GUI is however mostly overridable so one possible way of doing this could be to:
- Merge the backend changes
- Move the GUI changes to a separate theme, or a separate downloadable .zip file to drop in ~/.config/syncthing/gui
The code is then out there, I can set up and run my devices with it using a GUI patch or manual config hackery, the very interested can do the same without having to jump through hoops like building a custom version themselves. But the average user will remain protected from enabling it in the belief that it’s well tested and stable – until such a point we think it is stable.
Thoughts? Both on how to handle this specifically, and good ways of handling similar things in the future.
).