Open adaburrows opened 1 year ago
there is a lot of prior thinking that we can share from our experience of working on Acorn, and its version update pathways.
When deploying with electron, we are able to do soft update
releases, which represent any change for which the agents source chains can stay intact, which means the integrity zomes don't change, and the holochain
runtime version can still support the wasm. I don't know how this could be possible in a Launcher context, except via a hacky method that I told Viktor about where you go into your file system and replace the raw UI files with the replacements. Horrible /non-existent UX around that. This could be a feature request for Launcher, to allow UI updates.
When a hard update
is required, we are forced to think about the user experience both of 1. individuals, and 2. 'groups' (multiple people in a DHT) and how they will navigate the migration.
For the 'individual' scenario, things are simpler. One can perform a manual or automated 'replay' of the source chain data into the new version. This can still be delicate because hashes change, and so if there are any hash references in your data they need to change too.
For the 'multi-party' scenario, things are more complex. A scenario that is best avoided is one person migrating to a new DHT, while others carry on in the old one. This creates a divergence among the network. For this reason, we think it's best to 'freeze' activity in a DHT when one person triggers a migration on behalf of the whole group.
In addition to all that there are scenarios where the agents have new keys in the new DHT, but it can also be possible that the users prior keys are maintained during the update. Breaking changes to the keystore format are very rare.
What I would like is feed back to get a better understanding of when agents might receive a new identity. Normally, I'd read through the code, but currently don't have time to read through Holochain, the Launcher, the Keystore, and any glue that binds them together.
I don't know how this could be possible in a Launcher context, except via a hacky method that I told Viktor about where you go into your file system and replace the raw UI files with the replacements. Horrible /non-existent UX around that. This could be a feature request for Launcher, to allow UI updates.
I know someone else mentioned this, so I'll at least check to see if it's recorded in their backlog.
When a hard update is required...
The replay to the chain is a pretty simple engineering problem. You just need to be aware of the dependency graph between objects and foreign references and make sure that when you do a depth first traversal of the graph to create a new source chain you track the new references and replace the original references in the objects with the new ones. I did this kind of thing back in 2012 for exporting a sanitized version of data for use as test data. The hard part is ensuring you can build that graph.
Currently, we have a similar bit of code in the DataStore that can do this. Also, until we move to hREA we only use paths as references. So as long as we recreate all the paths in the correct order the migration is pretty seamless. The problem is that we haven't bothered to create a user facing interface to use expose this feature.
For this reason, we think it's best to 'freeze' activity in a DHT when one person triggers a migration on behalf of the whole group.
That's a good idea, but it seems like that's impossible to guarantee. It just always requires lots of out of band communication. Also, if it's done programmatically, it become a DOS attack vector, assuming the attacker can get the right keys to have the right capability grant to enable the freeze. It's unlikely to happen unless someone is just curious about what the 'Initiate upgrade' button does and the UI doesn't warn them.
@zippy posted up some feature requests / roadmap items for Launcher relating to 'soft updates' https://github.com/holochain/launcher/issues/71 https://github.com/holochain/launcher/issues/70
Awesome! That's going to help us a lot.
I was reminded about another aspect of all this when I started thinking about the signed-zome-calls changes. We really don't have a good onboarding process or upgrading process. While I've been thinking about the JSON export feature and using the local store for upgrades, there's still a certain amount of play and ongoing change that's unsettling to me.
Here's the current scenario (1):
Let's say we generate a different sort of workflow (scenario 2):
How does the admin become their regular user again to maintain the organization's principle of least access policy? How do other people created other organizations? Using the apps UID parameter?
Ok, so maybe we have something slightly different (scenario 3):
This makes makes sense. I like this kind of model. I think there's still some things to work out about it. But why should we stop with installation. How does upgrading work?
Upgrade scenario:
Is there any way to make this easier?