...
Improvement | Story | FIP | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
Support custom permissions in the SDK |
| N/A | ||||||||
Support alternate FIO Public Key for encryption of New Funds Request/Record OBT content blob |
| |||||||||
Support sending of FIO Tokens to an account |
| |||||||||
Support ability to create an account with custom permissions |
| |||||||||
Lift limit on number of public keys allowed in custom permissions |
| |||||||||
Extend permissions to custom FIO actions |
|
Improvements
Support custom permissions in the SDK
...
This enhancement would extend the FIO Chain permission scheme to enable granting of permissions in those cases.
Recommendation
...
Explore options to best achieve this and create a new FIP which will propose and implement the solution
Options contemplated:
...
Implementation
Add specific calls to allow domain owner to set address registration permissions on specific domain
Option 2: Create new FIO-specific permission scheme which would allow another account to execute FIO specific actions without customizing permissions on the call and while still acting as thei own account and pay their own fees. In other words more generic Option 1.
Account A owns Domain D
Account A wants to let Account B register (and pay for) FIO Address on Domain D
Account A executes updateauth with
permission: readdress-DomainD
actor: AccountB
Account B executes regaddress on DomainD (using its own standard permissions) and regaddress checks standard EOSIO permissions to see if above entry is present for Domain D and allows the registration even though domain is private
Option 3: Current EOSIO permissions hack to allow the owner of a Domain to specify permission using updateauth and have regaddress action inspect that permission when someone is trying to register a domain. For example: