chore: Add a hint to use offline derivation in the examples#263
chore: Add a hint to use offline derivation in the examples#263
Conversation
It is kind of a pain to use offline derivation in the examples themselves, due to needing to reliably handle (and thus distinguish) if they are using PocketIC or mainnet. But we can leave a hint to readers that they might want to use offline derivation themselves.
| // In production systems it would make sense to use the offline derivation | ||
| // support available in ic_vetkeys, eg DerivedPublicKey::derive_sub_key | ||
| // since this avoids the cycles and time overhead of a management canister call |
There was a problem hiding this comment.
Here the key is fetched every time anew. Some examples (like examples/basic_timelock_ibe/backend/src/lib.rs) use caching, so they fetch the public key only once. This makes this already much better. We could at least do the caching-based approach in all examples.
Another idea is to detect in which environment we are (mainnet vs pocket-ic) from the key ID: the key ID is passed to the init method and the init-args are defined in the dfx.json.
Ideally we can find a way to automate this (not necessarily in this PR), because this would help developers.
There was a problem hiding this comment.
Thinking about it more, detecting the environment would be nice, but it's not needed for the time being.
Adding the caching-based approach would already go a long way, and we can extend the hint that the caching could additionally also be done in the frontend, and that frontends could also use the Typescript-based offline key derivation if the caching is not possible (e.g., because there is no fixed context/input).
| // In production systems it would make sense to use the offline derivation | ||
| // support available in ic_vetkeys, eg DerivedPublicKey::derive_sub_key | ||
| // since this avoids the cycles and time overhead of a management canister call | ||
| let response: VetKDPublicKeyResult = ic_cdk::management_canister::vetkd_public_key(&request) |
There was a problem hiding this comment.
There is now also the encrypted_chat example, so maybe put the hint also there.
| // In production systems it would make sense to use the offline derivation | ||
| // support available in ic_vetkeys, eg DerivedPublicKey::derive_sub_key | ||
| // since this avoids the cycles and time overhead of a management canister call |
There was a problem hiding this comment.
Thinking about it more, detecting the environment would be nice, but it's not needed for the time being.
Adding the caching-based approach would already go a long way, and we can extend the hint that the caching could additionally also be done in the frontend, and that frontends could also use the Typescript-based offline key derivation if the caching is not possible (e.g., because there is no fixed context/input).
2 participants
It is kind of a pain to use offline derivation in the examples, due to needing to reliably distinguish if they are running against PocketIC or mainnet. But we can leave a hint to readers of the examples that they might want to use offline derivation themselves.