Hello, I’ve been reading the documentation and I get that one way hApps maintain security is to use a hash of the source code, it makes sense. But how something common like updating an app will happen? Every update I’ll lose the old chain?
1 Like
Connor of Sprillow here, I’ve been working on happs for a few years, and have maintained and developed Acorn https://github.com/h-be/acorn for 2 of them, and we’ve released many software updates to Acorn.
You’re technically right. That’s just a few considerations that make it not as bad as it seems.
(btw, maybe I can answer Managing updates and versions while I’m at it, since it seems to be the same)
The first place to start is separating out what the most important thing to have a hash of, for security purposes, is. The most fundamental thing to have the hash of is what are called the ‘validation rules’, since those are the thing central to the agreed upon definition of ‘data integrity’ for the purposes of the happ. The rest of the dna/zome source code is just api functions, and different ways of writing and reading to/from source chains and the DHT.
-
I have heard word that holochain core team is exploring the potential to make DNA hashes based on only validation rules + dna/zome configuration values. This would reduce how frequently these migrations of source chains and the DHT would need to happen. This is still speculative though, so this isn’t a solution (nor a complete solution anyways) for now.
-
User interface code is not included in the hash, therefore you can make user interface changes at will, without requiring users to migrate their source chains and the DHT. We do this sometimes with Acorn, where we publish a new version, but users keep their entire state without migrating.
-
When we need to make DNA changes:
in Acorn, there are UX improvements we could make to the migration process, but haven’t yet.
Users have to recreate their profile, but this could be automated on their behalf.
Users have to have exported 1 JSON file containing all the data for each ‘Project’ that they (and a team of collaborators) have on the old version. Once they’ve updated, they ‘import’ that project again into the new version. This creates one challenge: the provenance (cryptographic signatures) of all the data created by various users is somewhat broken, as all those entries now appear to be created by just one person. However, the public key of the original author is kept in the entry data itself, and therefore not lost. If that person joins the new DHT, and still uses the same public key, then that data will be at least superficially re-united with its original author.
What it should ideally do, that it doesn’t yet, is alert other users in a project that one of their collaborators has migrated the project to a new version. They have two choices: also upgrade, and join that user on the new version, or carry on using this version, in a diverged network from the original. This would be more like the project having experienced a ‘fork’. Not ideal.
It’s not yet to the level that users expect from apps, but that is not due to any hard limitation coming from holochain. We could make it quite smooth for users, with a good UX focus and applying lessons learned.
The point is, it takes thought, but is entirely possible, and will get easier and easier as we work out best practices.
9 Likes
Hi Connor, thank you for your detailed answer.
So let’s say I’m making a mutual credit app, in theory I would make the DNA functions to be the most important ones like send_credit or get_balance, and the rest would be running on the ‘client’ side either in rust or any other language that I’m using.
It’s not terrible because the fundamental functions would not be changed that much.
About your third point:
Users have to have exported 1 JSON file containing all the data for each ‘Project’ that they (and a team of collaborators) have on the old version. Once they’ve updated, they ‘import’ that project again into the new version.
When you say import data, you mean creating a new chain and dump all the data from the old chain to the new one?
then that data will be at least superficially re-united with its original author.
Can you expand on this a little? I’m sorry, I’m a bit new with all the concepts, so forgive me if this is a simple/dumb question but the superficial link between the pub key from the user and the data imported from the old chain would be connected how?
One example from the top of my head:
The company I’m working on is using Acorn, my boss gets an alert that a security bug was found in the DNA of acorn, and now we need to update the DNA. He exports all the projects to a JSON file containing the data (don’t know exactly what data this is), updates the DNA and imports all the projects.
In the JSON file that my boss imports the data, the owner id of a ticket would be created correctly? Like if we want to use the new chain data to verify who created a ticket or updated the status of one, wouldn’t everything now be created by my boss?
By the way I love your app, I think I was one of the first people to run Acorn after being posted on reddit.
1 Like
Right, that’s a good point. You could make your DNA source code VERY thin, and layer the vast majority of your business logic on the client side
2 Likes
thanks again, btw this link is dead: https://developer.holochain.org/concepts/concepts/10_migration/
1 Like
The broken link has “concepts” twice.
The correct link is currently working for me: 10. Migration: Updating A Network To a New Set of Rules - Holochain Docs
It’s also archived here: 10. Migration: Updating A Network To a New Set of Rules - Holochain Docs
1 Like