Document the verifier on-boarding flow

[aaitor]

On boarding process for verifiers

Introduction

The current Filecoin Registry application allows to the File root key holders to register manually verifiers in the different Filecoin networks.

The governance process for adding verifiers and the transactions history of that is an off-chain process that currently is not being tracked.

In this document we are proposing the changes to apply in order to have a more open and democratic governance framework with the objectives of:

• Facilitate the on-boarding of verifiers
• Make more open the whole process
• Make available the information about the state of the verification requests

On Boarding flow

Registering a Verifier on-boarding request on Github

The following flows allows to a user to request the on-boarding as Verifier. The steps are:

1. The users goes to the Filecoin Verifier Requests project on Github and request to open a new issue in a url like this: http://github.com/filecoin-project/verifier-requests/issues/new
2. Github will show a Template issue with a pre-configured set of information that a Verifier needs to provide. It includes:
   • Verifier Filecoin Address
   • Datacap requested
   • Url of the project
   • Additional comments
3. The user completes the information requested and click the "Submit new issue" button
4. The issue is created in the project and the labels open & state:Request are associated to the issue.

Approving a Verifier on-boarding request via Github

The flow proposed for on-boarding a verifier is:

1. The user goes to the home of the Registry application and in the top right menu toggle to the Root Key holder view
2. The user clicks in the Github login button to authenticate into Github
3. The user clicks in the new "Verifier On-boarding Requests" table
4. The application fetchs all the Github issues associated with the project "Filecoin Verifiers Requests" with the label: open.
5. The user can see in a table format all the requests sort by date. This will include the following information:
   • Verifier Address
   • State of the request "Request", "Further info needed"
   • Date of when the request was sent
   • Datacap requested
   • Description of the request
   • A button for "Grant Request"
   • A button for ask "More information"
   • A button for "Deny Request"

Actions:

1. If the user clicks the "Grant Request", this will propose a verifier getting from the Github issue description the Verifier Address & Datacap. If the transaction succeed the application will change the Github request to the state granted adding the label state:Granted and removing the label open. Additionally to this, a new comment to the issue will be added including the transactionId with the following format: Request granted: 0xTRANSACTION_ID
2. If the user clicks the "More Information" button, a small input text field will appear allowing to the user to specify what information is missing. When the user clicks the Submit button this will replace the state:Request label for state:Further info needed. Additionally to this a new comment with the information given by the root key holder will be added to the Github issue.
3. If the user clicks the "Deny Request", a small input text field will appear allowing to the user to specify why the request is denied. This information optional. If the user clicks the Submit button this trigger the following actions in Github:
   • The issue state label will be changed to state:Denied
   • The label open will be removed
   • If the user added any reason, a new comment will be added with that reason
   • The Github issue will be closed

This flows is based in the initial authentication of Github from the user side. It means for each request sent to Github, the application will send the user credentials allowing to Github to authorize or not the request sent by the user.

[aaitor]

@jnthnvctr , wdyt?