One of the great challenges of software is handling upgrades - they are a massive compatibility challenge as well as historically a significant security vulnerability. This means that widely deployed internet software changes slowly [See SMTP].
In the an ocap world , we expect changes (upgrades) to be frequent and rapid - especially as new applications provide new capabilities to the network. How do we make this easy and safe?
The big guys, such Netfix and Facebook, have strategies for upgrades in highly replicated, distributed systems. Systems written in Erlang also often have strategies for upgrading running systems. We should look at how they deal with the problem.
I don’t know that using capabilities makes things any harder. In fact, many of the existing systems are migrating to using OAuth 2 tokens, which they are using as capabilities.
Let me spell out the link here between the two explicitly: restoring a persistent restoration can be an opportunity for upgrade. Safe Serialization Under Mutual Suspicion does a nice job of laying this out, and since Spritely is taking that approach, it will likely be a common (if not the most common) place that upgrade occurs.
Any discussion of upgrade should include Arturo’s quote from that paper:
Do you, Programmer,
take this Object to be part of the persistent state of your application,
to have and to hold,
through maintenance and iterations,
for past and future versions,
as long as the application shall live?
Main benefit is that persistence has to recover from a crash at any time. If orthogonal persistence, it is clear what that problem is.
With persistence separated out, to a first approximation, upgrade can occur at a scheduled time that is arranged to be very safe. For a contract, for example, it could be a state with no live seats, if that is compatible with the nature of that contract.
By the way, I used that document, before I knew anything about ocaps but when I did know about actors, as a checklist of topics I needed to implement to build out the long-term vision of the technology I wanted. I recently noticed that @markm and Dean Tribble are cited in it.
Edit: Oh, Eric Tribble. I misread. (Are the two Tribbles related?)