Holochain 0.4 upgrade guide #499
Conversation
| @@ -0,0 +1,111 @@ | |||
| --- | |||
There was a problem hiding this comment.
The URLs in this document need to be updated once the Rustdoc is published to docs.rs
@ThetaSinner I've rewritten the guide; is this more what you're thinking now? |
|
|
||
| Edit any coordinator zome code that uses functions from `hdk::clone`: | ||
|
|
||
| ```diff:rust |
There was a problem hiding this comment.
Code compiles, functions not tested.
|
|
||
| Edit any client code that manipulates cloned cells: | ||
|
|
||
| ```diff:typescript |
There was a problem hiding this comment.
tsc can compile this too -- again not tested beyond "will it build".
pdaoust
force-pushed
the
2024-11-19-holochain-0.4-upgrade-guide
branch
from
e2aa445 to
99a00ac
Compare
| * **[Countersigning](/concepts/10_countersigning/) `unstable-countersigning`**: Allows agents to temporarily lock their chains in order to agree to write the same entry to their respective chains. | ||
| * **DPKI / DeepKey `unstable-dpki`**: Implements a distributed public key infrastructure, allowing agents to manage their keys and confirm continuity of their identity across devices and source chains. Read the [DeepKey readme](https://github.com/holochain/deepkey) for more info. | ||
| * **[DHT sharding](/concepts/4_dht/) `unstable-sharding`**: Lessens the load of each peer in large network, allowing them to take responsibility for validating and storing only a subset of a DHT's entire data set. | ||
| * **[Warrants](/concepts/7_validation#remembering-validation-results) `unstable-warrants`**: Spreads news of validation failure around the network, allowing peers to recognize bad actors and take action against them, even if they haven't directly interacted with them. |
There was a problem hiding this comment.
This feature is new and we know there are bugs which can result in Holochain writing data to your source chain that then prevent some data queries, use with caution
|
|
||
| ### JavaScript client now receives system signals | ||
|
|
||
| For JavaScript front ends and Tryorama tests, the signal handler callback for `AppWebsocket.prototype.on("signal", cb)` should now take a [`Signal`](https://github.com/holochain/holochain-client-js/blob/main-0.4/docs/client.signal.md). Update your code to look like this: |
There was a problem hiding this comment.
Can note here that system signals are currently only used for countersigning, which is disabled. So you can filter out system signals for now.
We are planning to use these for other things so it's probably worth making it clear that this is explicitly filtering them out.
| ### `InstallApp` agent key is optional | ||
|
|
||
| !!! info | ||
| This change is only relevant if you're building a runtime that can install hApp bundles. |
There was a problem hiding this comment.
If you're doing that, you might just as well be using Holochain as a library and need a whole other list of changes. I'd just say "using the Rust client to install apps on Holochain" or something like that here
|
|
||
| This feature needs more performance and correctness testing before it's production-ready, but it can be turned on by [compiling Holochain with the `unstable-sharding` flag enabled](#unstable-features-removed-by-default). | ||
|
|
||
| It's unknown exactly what might happen if nodes with DHT sharding disabled try to gossip in the same network as nodes without DHT sharding. Presumably this is still possible, but it might cause unexpected behaviors! |
There was a problem hiding this comment.
No, that is known. Because we've run with gossip_arc_clamping = "full" in the same network are peers with dynamic arcs before. It will work fine but the peers who have chosen to enable unstable-sharding and left their gossip_arc_clamping = "none" might run into bugs with arc sizing. That's the reason we disabled it and until we integrate Kitsune2 and re-enable sharding, we're not going to provide support for people who run into bugs with this. At least not beyond helping diagnose that this was indeed the issue.
|
|
||
| ### Dynamic database encryption, folder structure changes | ||
|
|
||
| Previous conductor and keystore SQLite databases used a hardcoded encryption key; v0.4 now uses a dynamic key. Additionally, the database paths have changed. These two things mean you won't be able to import data from v0.3. |
There was a problem hiding this comment.
There is an automatic migration of paths. If databases are detected at the old paths then Holochain will move them. We didn't provide a "re-encrypt" migration from the hard-coded key to dynamic keys though. It can be done, it's not impossible but we didn't think the value was high enough to justify the time.
So I'd word this to say that it's the encryption that prevents data being imported and if people want to keep their data they either need to export it through their app's UI and re-import on 0.4 or they need to provide their users with tooling to migrate the encryption keys.
Maybe that's a bit too much detail really, but conductor migration is something I'd like us to be getting better at over time :)
ThetaSinner
dismissed
their stale review
now able to update an app and have get it back to a running state
Incorporates all the breaking changes in 0.4 and peripheral tooling.