Security, Identity, Onboarding, and Upgrading

[adaburrows]

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):

1. A user installs the Launcher.
2. They start up the launcher and it asks them for a password for their keystore.
3. They install the webhapp.
4. (I didn't pay attention, what happens now? Is a new key pair generated to give the user a specific identity per app?)
5. They start the playspace.
6. They are asked for a profile name that does nothing.
7. Anyone can be anyone. Chaos reigns.

Let's say we generate a different sort of workflow (scenario 2):

1. (repeat original steps 1-5)
2. The playspace walks the first user through the admin setup. This lets them do a lot of things, including setting up the main organization agent, department agents, roles, permissions, and user agents.
3. They invite their organizations members into the playspace with links that tie the invitations to the specific user agents.
4. Each user that signs up has their newly minted key associated with the user agent that was assigned to them by the admin.
5. Permissions are in place.

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):

1. (repeat original steps 1-5)
2. The user ends up in a lobby. They can see other organizations that have been created. They can ask to join or create their own.
3. The user creates their own organization (clone the DNAs and create a new membrane).
4. (repeat steps 2-5 from scenario 2)

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:

1. If there are no breaking changes to validation, the membranes stay the same. No further action is required.
2. If the zome has changed considerably, it is treated as a new network. We have to set it up from scratch/maybe create it from an export. If we create it from an export, it may shave a little bit of time off the process and all of the exported data will be there, but fragmented from the original network. This means considerable effort will need to go into coordinating the upgrade across entire economic networks, unless there's a way to import the old zome proof and continue communicating with the old zome (this assumes the data structures/zome calls haven't changed to the point of incompatibility).
3. Even if we used the import, it is likely that everyone's key pairs will have changed. We will need to use steps 3-5 (in scenario 2) to reestablish the Holochain identity associations with the agents.

Is there any way to make this easier?

[Connoropolous]

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.

[adaburrows]

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.

[Connoropolous]

@zippy posted up some feature requests / roadmap items for Launcher relating to 'soft updates'
holochain/launcher#71
holochain/launcher#70

[adaburrows]

Awesome! That's going to help us a lot.