...

FIO Chain has implemented modifications of EOSIO in order to simplify the interaction with the chain, e.g. account creation and permissions. Since Mainnet a number potential improvements have been identified. The objective of this initiative is to evaluate and potentially implement these enhancements.

Tracking

Initiative

https://fioprotocol.atlassian.net/browse/

Dev Epic

https://fioprotocol.atlassian.net/browse/

Specific improvements

...

The primary difficulty with implementing this change, would be the coordination required to have integrators start using a different call to fetch the encryption call vs. the sending key.

...

Implementation

• Create a new FIP which will propose implement:

  • Addition of new field (or FIP-15 coding standard): encryption key to each account

  • Addition of new action (if FIP-15 coding standard not used) to modify encryption key

  • Addition of new getter to return encryption key (if FIP-15 coding standard not used) for a FIO Address

  • Migration process and backwards Backwards compatibility process

Support sending of FIO Tokens to an account

FIO Chain does not support a EOSIO transfer action, which takes account name as payee, and in turn requires the use of trnsfiopubky action, which requires a FIO Public Key. If one wanted to send FIO Tokens to a specific account, there is currently no easy way to get the FIO Public Key which hashes down to the account name. The key could be fetched from fio.address->accountmap table, but it requires complex table query logic. A more user friendly approach would be to create a custom getter which returns FIO Public Key for supplied account name, if one exists on chain. An alternative could be to support tokens being sent to an account.

...

Implementation

• Create a new FIP which will propose and implement:

  • Addition of new getter to return FIO Public Key for an account name

...

"We need the ability to create an account with a separate owner and active key. When creating accounts, we create the owner key and offer the backup sheet to safely store it - and then establish an active key locally on the device. The UX would break if we then had to create subsequent transactions to alter the permissions into this scheme and would also require the user paying fees."

Implementation

• Create a new FIP which will propose and implement:

  • Addition of new action to create an account with custom permissions. The action would carry a new fee.

...

"We need multiple active keys in our current configuration. Our account recovery process revolves around two options during recovery: first the ability to remove all active keys and set a new one (establish a new sole device), and the second being to add a new active key (which allows the addition of a new device)."

Implementation

• Create a new FIP which will propose and implement:

  • Removal of the restriction which only allows one FIO Public Key in updateauth

...

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:

  • Option 1: 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.

  • 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:

    • 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