Reflections: The ecosystem is moving

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}.

1. Compute - allows the transformation of one type of data to another.

2. Storage - allows the storage of data.

3. Network - allows the transfer of data from compute to storage, or vice versa.

Federation's historic constituents have been standards, payments and identity. In order for cloud federation to be viable, the primitives above must be able to be used in a way that allows some type of "standardized trust" to be applied, some type of identity to be associated with it, and some way of paying for the resources used.

One possible solution for implementing a Federated Cloud of Clouds is to use cryptocurrencies to pay for the processing of data, identify who's data it might be, and then encapsulate the data being federated into some type of standard. I have explored a generalized solution for this and have presented it to a few peers. It seems doable, if we can mobilize the development community's intent to change how software is written.

BTW, I don't consider "standards" to be anything other than a light consensus mechanism applied to a set of data which is then made immutable. One might consider a blockchain a "standard" by the evidence it is unchanging, once created.

Federation will only occur once we've moved infrastructure to using cryptocurrencies for deployments. It will also require a radical shift in the way we think about how software is written and paid for.

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.

What did Facebook do with email?