Definition of the architecture of the github on-boarding flows

[aaitor]

For all the on-boarding flows based on Github integration (see #18 & #19) we need to describe what is the techincal solution to put in place allowing to integrate the frontend and Github.

Reference doc: https://docs.google.com/document/d/1GW7_dJddOGx2b9JHDb5vpE8IpYXVzAipe08pV4EvskE/edit?ts=5f5a9ed1

[aaitor]

Filecoin On boarding architecture using Github

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

  The scope of this document is to define the architecture decisions to support these requirements using Github as repository of the the on boarding requests sent by verifiers and clients.

Architecture

In the proposed architecture Github provides the following functionalities:

• Repository of on-boarding requests
• Transaction log where can be found the verification requests and the whole governance flow applied during the process of granting or denying Filecoin on-boarding
• Authorization mechanism used to allow or deny the processing of on-boarding requests

Proposed solution

The existing on-boarding Filecoin Registry is a frontend application running in the user browser. Taking that into account and using Github as respository the recommend solution is to integrate via Github Apps in the frontend

Using this setup we would integrate the Github login and API in the frontend using the standard Github API. This would require:

• Create a new repo in the Filecoin Github organization to register the verification request issues
• Create a Github App and associate the permissions in the new repo
• Integrate the Github authentication flow via Github App using the Webflow
• Fetch issues via Github App filtering by label & state
• Update labels in issues, comment issues, close issues

More information here: https://docs.github.com/en/developers/apps/identifying-and-authorizing-users-for-github-apps

Authorization

To support a better security in the Github issues requests management it is recommended:

• Separate in 2 different repositories and Github apps the verifiers and clients requests
• Create 2 different users groups:
  • The "Root Key Holders" group would manage the Verifiers on-boarding requests
  • The "Verifiers" group would manage the Clients on-boarding requests
• Each individual Github App is linked to a specific group, so only the RKH github users can manage Verifier requests
• The full integration only will work when the users are authenticated via Github

[aaitor]

@jnthnvctr , happy to review later today