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?
[See also Conundrum: Orthogonal Persistence ]
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.
Links to resources to look at would be welcome!
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?
At Agoric we have both orthogonal persistence and upgrade. They are fully separated from each other, which turns out to be great. I had underestimated the benefits of this separation.
Indeed, it is quoted right at the top of the Heart of Spritely section on Safe serialization and upgrade, for that very reason!
This is interesting. Could you elaborate? A pointer to the mechanism, but more importantly, what’s the benefit?
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.
Interesting. I guess this makes more sense for a codebase where the code is literally part of the database that is being encoded, and a smart contract blockchain is particularly such a thing.
Is it fair to assume then that you’re not currently persuing any of the “safe serialization” jhu-paper type systems in Agoric’s codebase?
Re: orthogonal persistence, I am reminded of this phrase from Design requirements for network spaces which I think about often:
Run-time is all that there is.
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?)
“Dean Tribble”, “Eric Tribble”, “Eric Dean Tribble”, and “E. Dean Tribble” are all the same person 
Correct that our current serialization work is not based on the JHU paper.
Thanks for the reminder of Vijay Saraswat’s paper. Good stuff!