But if you look at mobile, we have central control of the code there without central control of the infrastructure: everyone has their own phone, yet runs the same apps that stay up-to-date via app stores.
Sandstorm is basically taking that model to servers: within 24 hours of an app update, everyone gets a notification and can click one button to update their copy, so everyone tends to stay up-to-date.
(Disclosure: I'm the lead developer of Sandstorm.)
That's just an excuse to not implement backwards compatibility in the protocol. Central control is also a security risk, as we've seen recently with Apple and the FBI. If the code is controlled centrally, the FBI (or whomever) only has to strong-arm one target.
> gets a notification and can click one button to update their copy
That sounds like you're trying to keep the user in control, which is great. I haven't head of Sandstorm before, but it sounds interesting.
Have you considered the problem of forced updates? I'm not sure there is a good way to protect against the FBI trying something similar to the recent drama with Apple, where they order you to force a "special" update on {someone,everyone}.
FWIW, Sandstorm is already designed to limit the possible damage from malicious apps in general, by making sure each app has only the minimum privileges it needs to do its job (and making sure the UX to grant said privileges is painless for the user). For example, we've seen quite a few security vulnerabilities in apps that were largely mitigated when running the app on Sandstorm:
https://docs.sandstorm.io/en/latest/using/security-non-event...
Hypothetically, in the Sandstorm model, you could architect a messaging app which is incapable of leaking messages to a third party: for each contact, you would create a separate grain (fine-grained instance, in Sandstorm terminology) of the app, and you would permit that grain to communicate only with that contact's corresponding grain they created for you. If the app cannot communicate with other grains of itself -- much less third parties -- then it cannot leak any communications.
Obviously, there are a lot of UX questions raised by this design. It is a goal of the Sandstorm project to solve those UX issues, and we believe they are solvable, but I can't claim to have all the answers today. More likely what you'd run today is a single grain which can talk to all your contacts. In this case an evil app update could almost certainly find a way to covertly leak any message through the network of contacts.
(And, of course, another issue, if communications are crossing the internet, is traffic analysis and covert channels embedded therein.)
So, yeah, there may or may not be a good technical solution here. But on the bright side, the Apple-FBI case seems to indicate that the government doesn't have the power to compel false signatures on code updates. I can only hope that interpretation stands and is reinforced over time.
When something like sandstorm can hide even the abstraction of server maintenance, and either: 1) Creating a service is background to account creation. Like say a private hosted sync point (choose your own host) is created when you install the application. 2) I can deploy via an account or "brand" I have established loyalty with, but maintain true portability.
These are new conversations, not possible before.