This PR encompasses a range of updates, including the refactored WASM32 SDK that now includes TypeScript bindings.
Special thanks to everyone supporting this initiative on Discord#development.
Key features:
Introduction of kaspa-resolver crate that represents a lightweight daemon connecting to multiple Rusty Kaspa nodes and offering an HTTP interface on which it provides the RPC URL of the least-loaded available Kaspa node instance.
This currently provides basic load-balancing features while simultaneously providing high availability as nodes can be brought down for maintenance without impacting users.
The corresponding Resolver() API allows the developer to supply an array of resolver URLs so that anyone can set up their own pool of nodes if desirable, as well as include community-hosted public infrastructure nodes.
The default Resolver() instance contains the list of public community-hosted resolver daemons. It can be queried directly or passed to the RpcClient. If passed, the RpcClient will use the resolver to obtain a wRPC WebSocket endpoint each time a disconnection occurs.
WebSocket-based RPC can also be easily proxied by mitigation service providers such as CloudFlare and routed via HTTP servers/balances such as NGINX and HAProxy. Some recipes for building Ubuntu Linux Rusty Kaspa node instances backed by systemd+nginx can be found in the khost project.
Refactor struct/data passing mechanics between Rust and JavaScript/TypeScript using custom CastToJs, TryCastFromJs, and other traits to optimize object cloning and properly handle data passed by the reference (using workflow-wasm/convert module). This refactoring optimizes performance and reduces memory footprint.
TypeScript/Rust bindings and interface declarations for all primitives exposed via the WASM32 SDK.
Rust RPC macros for WASM interfacing have been updated to accommodate and automate cross-referencing of interfaces for TypeScript documentation.
Automatically generated TypeDoc documentation buildable from source
Transaction serialization and de-serialization functions that convert Transaction or PendingTransaction to JSON, which can then be deserialized into Transaction. This can be used to manipulate and sign transactions using JSON. Serializations include regular JSON and "safe JSON" where safe JSON serialization converts all bignum values to strings and vice versa during deserialization.
Ability to build WASM binaries for different subsets of the WASM SDK
This release structure is included in CI during releases. Builds include all subsets of the SDK listed above, built as release and debug targets.
WASM32 SDK is compatible with:
NodeJs (via a loadable CommonJs module)
Web Pages (via a loadable ES6 module)
Frameworks such as NWJS and Electron
Google Chrome extension manifest v3
We've removed no-unsafe-eval feature from the framework by re-implementing functionality in Rust as well as updated various runtime detection functions to handle Electron frontend and backend processes.
The latest developer builds of this SDK can be found at:
This PR encompasses a range of updates, including the refactored WASM32 SDK that now includes TypeScript bindings.
Special thanks to everyone supporting this initiative on Discord#development.
Key features:
Introduction of
kaspa-resolvercrate that represents a lightweight daemon connecting to multiple Rusty Kaspa nodes and offering an HTTP interface on which it provides the RPC URL of the least-loaded available Kaspa node instance.This currently provides basic load-balancing features while simultaneously providing high availability as nodes can be brought down for maintenance without impacting users.
The corresponding
Resolver()API allows the developer to supply an array of resolver URLs so that anyone can set up their own pool of nodes if desirable, as well as include community-hosted public infrastructure nodes.The default
Resolver()instance contains the list of public community-hosted resolver daemons. It can be queried directly or passed to the RpcClient. If passed, the RpcClient will use the resolver to obtain a wRPC WebSocket endpoint each time a disconnection occurs.WebSocket-based RPC can also be easily proxied by mitigation service providers such as CloudFlare and routed via HTTP servers/balances such as NGINX and HAProxy. Some recipes for building Ubuntu Linux Rusty Kaspa node instances backed by systemd+nginx can be found in the khost project.
Refactor struct/data passing mechanics between Rust and JavaScript/TypeScript using custom
CastToJs,TryCastFromJs, and other traits to optimize object cloning and properly handle data passed by the reference (using workflow-wasm/convert module). This refactoring optimizes performance and reduces memory footprint.TypeScript/Rust bindings and interface declarations for all primitives exposed via the WASM32 SDK.
Rust RPC macros for WASM interfacing have been updated to accommodate and automate cross-referencing of interfaces for TypeScript documentation.
Automatically generated TypeDoc documentation buildable from source
Transaction serialization and de-serialization functions that convert
TransactionorPendingTransactionto JSON, which can then be deserialized intoTransaction. This can be used to manipulate and sign transactions using JSON. Serializations include regular JSON and "safe JSON" where safe JSON serialization converts allbignumvalues to strings and vice versa during deserialization.Ability to build WASM binaries for different subsets of the WASM SDK
This release structure is included in CI during releases. Builds include all subsets of the SDK listed above, built as release and debug targets.
WASM32 SDK is compatible with:
We've removed
no-unsafe-evalfeature from the framework by re-implementing functionality in Rust as well as updated various runtime detection functions to handle Electron frontend and backend processes.The latest developer builds of this SDK can be found at:
CHANGELOG for the most recent developer release can be found here: https://github.com/aspectron/rusty-kaspa/blob/typescript/wasm/CHANGELOG.md
Building from source, SDK folder structure, examples etc., can be found in the WASM SDK README (in the
/wasmfolder)When building from source, ensure that you have proper a development environment setup as described in the main Rusty Kaspa workspace README.md
The following work in progress is getting included in this PR in the prototype form and will be updated later in separate PRs: