-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
allow third party services to charge the user #445
Comments
I'm not a fan of this. Erc20 is specifically meant for general purpose assets on top of ethereum, while TFT is already a native currency on tfchain. Furthermore, in this context, we use a Specifically, I'm thinking off something like this:
The above follows the trend of using contracts, which means after creation a user does not need to care anymore. Furthermore you can track easily per contract how much you pay over time, how much you can pay maximum, and you don't have to continuously increase your allowance for some 3rd party. |
@xmonader @LeeSmet Here is another approach to be considered. We can have a contract with This approach won't expose public pinning API. pinning and unpinning will mainly be done by listening to chain events. We could also have a hybrid approach to make the API follow the specs of IPFS pinning service. like after sending the content hash to the |
@xmonader please put an assignee if already on 'accepted ' |
@LeeSmet please prepare the specs for this and have consensus with @DylanVerstraete to move forward |
Since we don't want to do work on the chain for every possible 3rd party service, we will keep this as generic as possible. While custom implementations for services might offer small advantages in the flow, the extra effort to develop and most importantly maintain these implementations is not worth it compared to a proper generic flow which would technically also be reusable. Contract structureA contract will work simple client - server principle (i.e. the "buyer" and the "seller", a "consumer" of a service and one who "offers" the service). Both parties are identified by a twin id to fit in the current flow (we could use a generic address as well here). Contract is laid out as such
Additionally, we also keep track of some metadata, which will be:
BillingOnce a contract is accepted by both the consumer and the service, the chain can start accepting "bill reports" from the service for the contract. Only the twin of the service can send these, as specified in the contract. The bill contains the following:
Chain callsCallable by anyone
Callable by consumer or service
Callable by service
Callable by user
FlowWe start of by creating a contract. This can technically be done by anyone, but in practice will likely end up being done by either the service or the consumer (depending on what the service expects). This will be followed by the service or consumer setting the metadata (again depending on how the service expects things to be), and the service setting a base fee + variable fee. Note that part of the communication can and should be off chain, the contract is only the finalized agreement. When the fees and metadata are set, both the consumer and service need to explicitly approve the contract, setting the appropriate flag on the contract. Note that as soon as either party accepted (i.e. either flag is set), the fees and metadata cannot be changed anymore. It is technically possible for consumers to accept a contract as soon as it is created, thereby not giving the service a chance to set the fees. Though this basically means the contract is invalid and the service should just outright reject it. Once the contract is accepted by both the consumer and the service, it can be billed (i.e. bills send before both flags are set must be rejected). Because a service should not charge the user if it doesn't work, we will require that bills be send every hour, by limiting the window size to 3600. Anything with a bigger window is rejected. This way if the service is down (for some longer period), it for sure can't bill for the time it was down. When the bill is received, the chain calculates We will not implement a grace period for this right now, as the service should define on an individual basis how this is handled. If needed in the future this can of course change. |
Progress on tfchain: #495 Things left to do here:
|
Need a status update here, as this was rebased on the work of the power mgmt and the capacity planning? @renauter @DylanVerstraete ? |
Power mgmt and the capacity planning was reverted |
First version of 3rd party service contracts is deployed on Devnet! @xmonader, all related issues are tagged in |
according to the erc20 interface
these functions support third party billing, where
The text was updated successfully, but these errors were encountered: