You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bitlight is proposing a flexible and customizable storage solution for its wallet implementation, which can be integrated with various storage backends, including but not limited to FS. Previously, the project relied on two key functions in bp-wallet: BpWallet::detach (to extract the internal wallet structure) and BpWallet::restore (to restore the wallet from a stored state).
Problem
With the removal of the BpWallet::detach and BpWallet::restore APIs in the Beta7 release of bp-wallet, there is a need for a more generalized and versatile approach to wallet storage and recovery. This would provide downstream development projects with a seamless transition and an effective alternative for implementing their storage solutions.
Proposal Goal
This RFC proposes a new design pattern for bp-wallet that provides a generalized and extensible persistence interface. This design will offer a standard interface for downstream projects to implement custom storage backends, while also ensuring high performance and compatibility with existing projects. The proposed design will maintain synchronous APIs to avoid breaking changes, while still allowing for asynchronous storage operations internally.
Additional Notes
Since there is currently no RFC submission process available under the bp-wg organization, this proposal is being submitted under the rgb-wg organization. If needed, I am fully prepared to adjust the proposal's placement and design according to your guidance.
Next Steps
Once we have reached an agreement on the approach, the Bitlight team is prepared to assist in developing and implementing this proposal within bp-wallet.
Wallet Persistence Design Document
Initial Consideration
The initial plan was to implement all APIs asynchronously. However, making the persistence operations asynchronous would require significant changes to the existing codebase, as all public APIs in bp-wallet are currently synchronous. Converting these APIs to asynchronous would introduce a substantial breaking change, especially since persistence operations are typically triggered during the execution of public APIs or when an object is dropped.
For downstream developers, it's crucial that bp-wallet can automatically persist wallet data during runtime using a user-defined storage mechanism, without requiring explicit calls to detach for saving internal fields.
To avoid extensive refactoring and maintain the synchronous nature of the current APIs, this proposal outlines two synchronous persistence design approaches for the Wallet structure.
Tip: If asynchronous storage is required (e.g., for S3), user can use block_on or similar methods within the StoreProvider synchronous API to execute asynchronous operations, thereby achieving asynchronous persistence without altering the public APIs.
Approach 1: Unified StoreProvider Synchronous API Design
Design Overview
In the first approach, a unified StoreProvider trait is used to handle the persistence of all parts of the Wallet. This design centralizes all storage operations within a single trait, where bp-wallet serializes the data as strings or bytes before passing it to the StoreProvider. Users only need to implement the storage logic.
Loading the Wallet: The StoreProvider interface is used to load descriptions, data, cache, and Layer 2 data, which are then deserialized.
Saving the Wallet: The save method serializes each component of the Wallet and stores them using the StoreProvider if the dirty flag is set to true.
Auto-Save on Drop: The Wallet automatically saves itself when dropped if the dirty flag is true.
Advantages
Unified Interface: All storage operations are managed through a single StoreProvider interface, simplifying the API design.
Reduced Implementation Complexity: Users only need to implement one StoreProvider trait.
Approach 2: Multiple StoreProvider Synchronous API Design
Design Overview
The second approach is more flexible, allowing each component of the Wallet (such as descriptions, data, cache, and Layer 2 data) to use separate StoreProvider implementations. This enables different storage strategies for each component. This design was inspired a lot by your PR, thank you so much for exploring.
Loading the Wallet: Each part of the Wallet is loaded using its corresponding StoreProvider.
Saving the Wallet: The save method saves each part of the Wallet using its respective StoreProvider if the dirty flag is set to true.
Auto-Save on Drop: The Wallet automatically saves itself when dropped if the dirty flag is true.
Advantages
Flexible Storage Strategies: Different storage strategies can be used for different parts of the Wallet.
Fine-Grained Control: Developers can implement different StoreProvider traits for different components as needed.
Comparison and Selection
Unified Interface vs. Flexibility:
The first design provides a unified interface, simplifying storage implementation.
The second design offers greater flexibility by allowing different storage strategies for each component.
Complexity:
The first design is simpler and better suited for scenarios where storage needs are consistent.
The second design is more complex but ideal for cases requiring varied storage strategies.
Conclusion
Both designs maintain the synchronous API nature, avoiding large-scale refactoring of the existing codebase. The choice of which design to adopt depends on the specific requirements of the use case. If the application needs to handle different storage strategies for various parts of the Wallet, the second design is more suitable. Otherwise, the first design offers sufficient flexibility with simpler implementation.
Tip: For scenarios requiring asynchronous storage (such as S3), block_on or similar techniques can be employed within the synchronous StoreProvider API to perform asynchronous operations, thus achieving asynchronous persistence without modifying the public APIs.
This RFC outlines the problem, proposes two different approaches for the solution, and provides example code to illustrate each design. The goal is to allow bp-wallet to offer a generalized, customizable, and efficient persistence solution that supports various backend storage options without requiring significant changes to existing APIs.
The text was updated successfully, but these errors were encountered:
We have to be careful when using futures::executor (or even tokio::task): both don't work well when we compile in wasm (to use in web extensions, browser APIs, etc...), because the browser doesn't allow block threads.
Background
Bitlight is proposing a flexible and customizable storage solution for its wallet implementation, which can be integrated with various storage backends, including but not limited to FS. Previously, the project relied on two key functions in
bp-wallet
:BpWallet::detach
(to extract the internal wallet structure) andBpWallet::restore
(to restore the wallet from a stored state).Problem
With the removal of the
BpWallet::detach
andBpWallet::restore
APIs in the Beta7 release ofbp-wallet
, there is a need for a more generalized and versatile approach to wallet storage and recovery. This would provide downstream development projects with a seamless transition and an effective alternative for implementing their storage solutions.Proposal Goal
This RFC proposes a new design pattern for
bp-wallet
that provides a generalized and extensible persistence interface. This design will offer a standard interface for downstream projects to implement custom storage backends, while also ensuring high performance and compatibility with existing projects. The proposed design will maintain synchronous APIs to avoid breaking changes, while still allowing for asynchronous storage operations internally.Additional Notes
Since there is currently no RFC submission process available under the bp-wg organization, this proposal is being submitted under the rgb-wg organization. If needed, I am fully prepared to adjust the proposal's placement and design according to your guidance.
Next Steps
Once we have reached an agreement on the approach, the Bitlight team is prepared to assist in developing and implementing this proposal within
bp-wallet
.Wallet Persistence Design Document
Initial Consideration
The initial plan was to implement all APIs asynchronously. However, making the persistence operations asynchronous would require significant changes to the existing codebase, as all public APIs in
bp-wallet
are currently synchronous. Converting these APIs to asynchronous would introduce a substantial breaking change, especially since persistence operations are typically triggered during the execution of public APIs or when an object is dropped.For downstream developers, it's crucial that
bp-wallet
can automatically persist wallet data during runtime using a user-defined storage mechanism, without requiring explicit calls todetach
for saving internal fields.To avoid extensive refactoring and maintain the synchronous nature of the current APIs, this proposal outlines two synchronous persistence design approaches for the
Wallet
structure.Tip: If asynchronous storage is required (e.g., for S3), user can use
block_on
or similar methods within theStoreProvider
synchronous API to execute asynchronous operations, thereby achieving asynchronous persistence without altering the public APIs.Approach 1: Unified
StoreProvider
Synchronous API DesignDesign Overview
In the first approach, a unified
StoreProvider
trait is used to handle the persistence of all parts of theWallet
. This design centralizes all storage operations within a single trait, wherebp-wallet
serializes the data as strings or bytes before passing it to theStoreProvider
. Users only need to implement the storage logic.StoreProvider
TraitWallet
Structure and MethodsWallet
: TheStoreProvider
interface is used to load descriptions, data, cache, and Layer 2 data, which are then deserialized.Wallet
: Thesave
method serializes each component of theWallet
and stores them using theStoreProvider
if thedirty
flag is set totrue
.Wallet
automatically saves itself when dropped if thedirty
flag istrue
.Advantages
StoreProvider
interface, simplifying the API design.StoreProvider
trait.Approach 2: Multiple
StoreProvider
Synchronous API DesignDesign Overview
The second approach is more flexible, allowing each component of the
Wallet
(such as descriptions, data, cache, and Layer 2 data) to use separateStoreProvider
implementations. This enables different storage strategies for each component. This design was inspired a lot by your PR, thank you so much for exploring.StoreProvider
TraitWallet
Structure and MethodsWallet
: Each part of theWallet
is loaded using its correspondingStoreProvider
.Wallet
: Thesave
method saves each part of theWallet
using its respectiveStoreProvider
if thedirty
flag is set totrue
.Wallet
automatically saves itself when dropped if thedirty
flag istrue
.Advantages
Wallet
.StoreProvider
traits for different components as needed.Comparison and Selection
Conclusion
Both designs maintain the synchronous API nature, avoiding large-scale refactoring of the existing codebase. The choice of which design to adopt depends on the specific requirements of the use case. If the application needs to handle different storage strategies for various parts of the
Wallet
, the second design is more suitable. Otherwise, the first design offers sufficient flexibility with simpler implementation.Tip: For scenarios requiring asynchronous storage (such as S3),
block_on
or similar techniques can be employed within the synchronousStoreProvider
API to perform asynchronous operations, thus achieving asynchronous persistence without modifying the public APIs.Mock Code Examples (Draft Version)
Approach 1
Approach 2
This RFC outlines the problem, proposes two different approaches for the solution, and provides example code to illustrate each design. The goal is to allow
bp-wallet
to offer a generalized, customizable, and efficient persistence solution that supports various backend storage options without requiring significant changes to existing APIs.The text was updated successfully, but these errors were encountered: