Hyperwallet as a package #804
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Problem
Currently, Hyperware processes that require blockchain interaction must manage their own cryptographic keys and construct raw transactions. This is complex and error-prone.
Solution
Hyperwallet could solve that through being a service that provides Hypeware-process-isolated wallet management. It acts as a trusted "wallet-as-a-service" provider, allowing applications to perform cryptographic operations pretty intuitively.
Initially this was developed as a stand-alone process paired with the development of Hypergrid , so most of the focus has been on wallet operations in that scope.
TBD: when is this in good spot to merge-in as a distro package? The main issue would be to have to do breaking changes between versions.
Note: There has been no work in mutating this from a standalone process to an actual package yet.
Quick overview
A) This PR adds two main components:
A new
hyperwalletpackage: This is the standalone server process that manages all state, permissions, and cryptographic operations.A new
hyperwallet_clientmodule withinhyperware_process_lib: A client library that provides functions for all other processes to interact with the Hyperwallet service. PL branchB) The core design principle is Process Isolation: wallets are strictly owned by the process that creates them, and no other process can access them.
C) Each new or updated process needs to go through a little Handshake flow.
ClientHello: Client introduces itself and its version.ServerWelcome: Server (should) respond with its version and capabilities (supported operations, chains).ClientRegister: Client declaratively states its required permissions.ServerComplete: Server confirms registration and returns asession_id.there's also the
initializefunction the hyperwallet_client lib.When an application is updated and requires new permissions, it declares its new full set of requirements during the handshake on its next startup. The Hyperwallet process updates the permissions, along with a version change (should be a bump)
Each handshake establishes a session identified by a
session_id, mainly to make it easier to handle wallets imported/generated with a password.TODO: