Open avahowell opened 7 years ago
it would be better that it gives more exact how much storage size if, i even don't know how much space i rent after the allowance setup
Having a second wallet module greatly increases the complexity of the application, although I could see why having a wallet used only by the contractor could be an interesting security feature, on top of the obvious UX improvements.
I think an easy feature we could implement that would greatly improve the UX is to set sane checks for the allowance size vs. time length. We should give greater visibility of what the allowance is buying, and how much SC they would be paying on the monthly basis.
Given that contract fees are fairly high, people setting a small amount of SC (100-500SC) as an allowance will have most of the SC eaten away by the contract, and they will be confused as to why they can't upload/download files from the contract.
What we need for sure is 1) a way to show what part of the allowance has been used up (maybe both what has been put into contracts and what of that has actually been used up) and 2) a way to add more allowance if whatever was set is actually (close to being) used up.
add "Feature Request" Label.
Motivation
The behavior of Sia's "allowance" abstraction, the mechanism by which the core use case of Sia is exposed, is currently very hard to understand from a user's perspective. The main point of confusion is the manner in which money is deducted from the wallet to form contracts: instead of a single transaction exactly the size of the allowance set appearing as a deduction in their transaction list, they see dozens/hundreds of small deductions as the contractor forms contracts. In addition, there are cases where the contractor can inadvertently spend more than the allotted amount. This proposal outlines a simple change to the allowance mechanism that will greatly improve user experience.
Goals
Solution
The contractor currently interfaces with the user's wallet module, in order to build the transactions required for contract formation, renewal, upload, and download. As previously mentioned, this leads to undesirable user experience: it's not clear when and where the allowance is deducted from the user's wallet, or which transactions represent which actions.
The contractor should embed a secondary wallet module. When a user sets an allowance, a transaction will be created that sends the exact sum of the allowance from the user's wallet to the contractor subwallet, and the contractor will use this subwallet to create the transactions used to form and renew contracts. The allowance amount should be sent from the main wallet to the subwallet once per allowance period. If a period elapses and there are unspent allowance funds, the unspent amount should be sent back to the main wallet. In addition, the subwallet's seed should be deterministically generated from the main wallet's seed.
The API should expose endpoints that give an accurate overview of how the money allotted to the contractor is being spent in that period. Sia-UI will implement a segmented progress bar which displays clearly how the amount allocated to the contractor is being spent.
Considerations
Currently there are performance concerns surrounding running another wallet module that must sync with the consensus set. Some of these may be mitigated by omitting the initial rescan for the contractor wallet where appropriate. A small performance penalty may be acceptable for significant UX gains, and focusing some effort on a more performant wallet is desirable regardless.