Links

• FIP-40

  • fips/fip-0040.md at master · fioprotocol/fips

• fio.contracts

  • FIP-40 establish permissions, integrate register_address_on_domain. by edrotthoff · Pull Request #297 · fioprotocol/fio.contracts

  • include link to FIP and Epic/Story

• fio.devtools

  • FIP-40 modifications for fio.devtools by edrotthoff · Pull Request #72 · fioprotocol/fio.devtools

• fio.test

  • FIP-40 testing by edrotthoff · Pull Request #344 · fioprotocol/fio.test

• fio

  • FIP-40 changes to FIO Core. by edrotthoff · Pull Request #373 · fioprotocol/fio

• fiosdk_typescript

  • branch feature/FIP-40-fiosdk_typescript-develop-05112023 – adds getters to the sdk

  • branch FIP-40-fiosdktypescript-develop-03202023 – adds fio.perms contract to the set of abi loaded.

  •  

Design

[FIP-40] Detailed Design

Questions.

1. managing pre-existing permissions when * is used for object name in add perm by an owning account

use case

account a owns many domains, they begin to call add perm for these many domains (lets say hundreds to thousands of domains), and they call add perm for account using the domain name for the object name.

then the account learns of the *, they then use the * to create the same permissions. this introduces a possible data issue, we have many thousands of pre-existing records in the permissions table, and we are adding the *.

possible approaches for this use case.

1. leave the existing data in the permissions table. always look for the * first when looking up permissions.

   1. this implies users need to invoke remperm themselves to clean up the data. they would invoke remperm for domains that have been used other than *

2. The system might perform the cleanup when the * is used. this introduces a performance concern, as there may not be enough time to remove the many permissions when there are many domains involved.

3. if * is used and other permissions pre exist for other domains, the user could experience an error (“cannot use * with other domains specified, please remove other domains before add perm ).

Answer: from pawel. we will select option 1, leave the permissions as they lay, look for *, and look for the named domain when checking for hasAccess.

Summary of changes to fio and fio.contracts

• fio

  • Note files that will be updated

• fio.contracts

  • FIP-40 establish permissions, integrate register_address_on_domain. by edrotthoff · Pull Request #297 · fioprotocol/fio.contracts

Actions and Endpoints

please refer to FIP. and fio.contracts PR.

Structs and ABIs

• new ABI for fio.perms

Tables

• new tables in fio.perms

• permissions, and access. see PR above fio.perms.cpp and fio.perms.hpp for details.

Risks

• Summary of risks, impacts and logistics analysis

Functional Unit Testing

Design

• Overview of functional unit testing plan with high-level bulleted test cases

Results

• Link to JS tests and description of which test sections were updated/added

• Paste results of tests

Performance Testing

Design

• Overview of test plan with high-level bulleted test cases

Results

• Summary of performance tests that were run and results

Fork Testing plan

• List all of the pertinent tests, required setup, and expected results.List all pertinent tests pertaining to testing with different versions of the core code.

• List all pertinent tests pertaining to pre-contracts update and post contracts update

SDK Requirements

• Note functional updates needed for SDKs

Rollout/Release plan

• Make a comprehensive list of all necessary changes

• Include (new actions, removed actions, MSIGs for all required operations, and step by step instructions.

Rollout/Release verification plan

• Include step by set instructions for how to verify that the changes are on chain after rollout.

• Bonus points if you make an automated script performing the verifications.