Open TheTaconator opened 6 years ago
Good writeup!
IMO all history should be moved into an external database, i. e. ES. And I'm all for moving non-core functionality into plugins.
- (Optional) A recipient may request withdrawal authorization from a potential giver.
- A giver may granting the withdrawal authorization to the recipient.
As mentioned in OP, these can be done with proposals.
Querying Withdrawal Authorizations
Need to develop new API's.
Overview A recurring/scheduled withdrawal on BitShares consists of one account (e.g. donor; customer; etc.), which will be called a "giver", authorizing another account, which will be called a "recipient", to withdraw up to a maximum amount ("limit") of assets during any one of defined periods (e.g. per week; per month; etc.) between a start date-time and for up to N quantity of periods (i.e. an implied end date).
This functionality already exists in BitShares Core as of 2.0.171105a. However, this capability does not exist in the GUI reference wallet nor in the command-line interface (CLI) which are two "clients" to the blockchain. Both of those clients require an ability to query the present and past state (i.e. history) of withdrawal authorizations and withdrawals as they exist on the blockchain. That, in turn, requires changes to the API node.
Needed Functionality (Optional) Requesting Withdrawal Authorization
(Optional) Informing a Potential Giver about a Withdrawal Authorization Request
(Optional) Reviewing Withdrawal Authorization Requests
Authorizing Withdrawal
Rescinding Withdrawal Authorization
Querying Withdrawal Authorizations
Query expired authorization requests from a recipient
Query expired authorization requests by a giver
Query current authorizations from a recipient
Query current authorizations by a giver
Query expired authorizations from a recipient
Query expired authorizations by a giver
Executing Withdrawals
Querying Withdrawals
Implementation Considerations Almost every single feature above will require enhancements to client software (such as the reference GUI wallet for use by a typical end-user, and a CLI for a typical recipient) and API nodes to enable querying the existing state of withdrawal authorizations.
One consideration regards the optional first step: a potential recipient can request that a giver grant withdrawal authorization. This can be implemented as a proposed transaction that is submitted by a potential recipient, and reviewed by a potential giver on the client of their choice.
One debatable implementation is which functional entity (API node or client) should enumerate for an end-user the various period start and end dates that are implied by the withdrawal authorization. The nodes already know the the current period's end date but does not retain in memory prior periods nor subsequent periods. Therefore, the API node could calculate and provide this information. However, it is probably better to offload this calculation to the client software; a weakness to this approach is that it introduces the potential of client software incorrectly calculating the start and end dates and thereby misleading the end-user.
Another consideration is whether the functionality in the API should be written as a plug-in. I currently think that this functionality should be available on all API nodes because any user anywhere might be inquiring about withdrawals. However, perhaps an argument could be made that it should be possible to limit the history of withdrawal authorizations and actual withdrawals from active memory of the API node. Should limited history be a parameter that can be limited on any API node? Should full history only be available by making use of, perhaps, the elastic search plugin? Note: Should history also include the proposed withdrawal authorization from the Optional Step 1, or is Step 2 adequate?
Feedback I would appreciate any feedback regarding this functionality