Currently we show the following for a transaction:

This can be confusing for users because:

• It may not be clear what the associated t0 is for a t1 account (because we're finding it behind the scenes)
• It may not be clear that the user has to go to the ledger to approve the action

I propose that to fix this we add a section that explictly states what they should see on their ledger (and prompt the user to check the ledger to confirm the transaction) to move forward. Something like:

• Your transaction is to send: 1 TiB of Data Cap to t080 (the associated address for t1x...) from t1n... . Please confirm on your ledger this is correct to complete the transaction.

Analyze the information displayed on the different screens of the design.
Discern what is the info we can get from the current API (for instance to get the Remain Datacap we can get the list of verifiers and sum their datacaps), and think about how we could get the rest of the info.
Probably we can get some of this info directly from the state tree, but for some we will need additional mechanisms, like block explorer integration or store off chain data in a db

We should change this flow so (to start) we only have this table view for clients.

To make this usable, I think we shoudl add a "Use Case" column (between verifier and geography).
I think we should also take out the "email / github" columns - and instead embed this in the form. Perhaps we could have the last question say "choose how you'dl like to contact this verifier", and you can get a radial select - "Email", "Public Github Issue"... etc

NOTE: This design is complemented by: #26

How applications can on-board their users in Filecoin?

Introduction

The current Filecoin Registry application allows to the verifier to allocate some of their datacap to clients. This is okay from a functional point of view because there is a mechanism to distribute the datacap from the verifiers to the associated clients to that verifier.

Also there are applications like Slate wanting to provide storage capabilities to their users using Filecoin as substrate. To support that capabilities, all the new Slate users should be able to receive automatically a datacap allocation from the verifier associated with that application (Textile in this case).

The current manual flow supported in the Filecoin registry application is totally functional but is not optimal for supporting automatic datacap allocation.

The objective of this document is to describe the technical solution allowing to allocate datacap in an automatic way to clients/users of these Filecoin applications.

Architecture

Here we distinguiss different actors:

• The VERIFIER (Textile for example)
• The CLIENT running an APP (Slate for example)
• The USERS of the APP (Slate users able to sign up in the website)

To support the level of automation required, there will be a micro-service (aka SERVICE) with the following characteristics:

• An instance of this micro-service must be executed for each VERIFIER (like Textile) requiring to automate the datacap allocation for the APP USERS (like Slate users)
• When a new USER is registered in the APP (like Slate or similar) using the APP sign-up process, this APP will send a datacap requests for the USER just registered to the SERVICE run by the VERIFIER
• The SERVICE will authenticate the datacap request coming from the APP via pre-shared token (aka PSK). The PSK identifies to a specific CLIENT (Slate in this case)
• The APPs will have a pre-allocation of datacap in the VERIFIER for all their potential USERS
• The SERVICE will expose a REST interface in the following endpoint POST /verifier/client/datacap. The PSK will be sent in the HTTP Authorization header. This endpoint will request the following JSON payload as input:

  {
    "clientAddress": "t01032",
    "applicationId": "LIKE_SLATE_ID",
    "userId": "INTERNAL_USER_ID",
    "datetimeRequested": "2020-02-08T08:13:49Z"
  }
  

• The SERVICE will authenticate the user via PSK
• The SERVICE will authorize the user request checking in the internal configuration if there is the existing allocation and mapping between the PSK and the client address and the client total datap pre-allocation
• In the internal configuration of the SERVICE this should have the key material related with the VERIFIER and allowing to interact with the Filecoin network via lotus node. Also the configuration will include a default datacap allocation for clients (1gb?). Each VERIFIER running the SERVICE depending on their needs can modify this configuration to allocate more or less datacap to new APP USERS.
• The SERVICE checks the existing allocation of the CLIENT (in this case Slate) to validate if there is datacap available to share. If that's the case the service allocate the datacap for the user.
• If everything goes right the SERVICE will return a response like this:

  HTTP 201
  {
    "clientAddress": "t01032",
    "applicationId": "LIKE_SLATE_ID",
    "userId": "INTERNAL_USER_ID",
    "datetimeApproved": "2020-02-08T08:13:49Z",
    "transactionId": "0x1234567890abcdeefgh1234567890abcdeefgh",
    "datacapAllocated": "1000000000000"
  }
  

• If the request can't be processed the SERVICE will return a response like this:

HTTP 401 or 500
{
  "clientAddress": "t01032",
  "applicationId": "INTERNAL_APPLICATION_ID",
  "message": "The verifier can't distribute more datacap at this time"
}

• As owner of the SERVICE, I can attestate the datacap requests writing the output of the previous method and writing into IPFS or similar
• The technologies suggested for this service are Node.js and Express for the micro-service implementation
• It's recommended to have the SERVICE as much isolated possible from a networking point of view

Confirm with Riba if mainnet deployment needs any specific setup

According with the designs, the frontend should show more friendly information about the verifiers and the clients (names, alias, logos, urls, …) To accomplish this goal it should exists an off chain mechanism, like a db, to persist this kind of info, and be able to merge on the screen the on chain info with the related off chain info.

Probably the responsibility of filling or persisting this info is out of the scope of the frontend app

In the GithubRouter class the github credentials are hardcoded and accessible in the public repo. This should use environment variables.

Not sure if this is a bug, or can be resolved elsewhere - but when confirming the message in my ledger I noticed it never actually mentions the data cap.

The Value field seems to only refer to FIL, not to potential data cap - and theres nothin gin the Method or Params that indicates what amount of data cap I'm actually trying to send/

Investigate alternatives

This Service will allow to the different apps on the Filecoin's ecosystem to verify their clients in an automated way.
Firstly we need to implement the basics of the Service using Node.js and a thin framework like Express

Related with #39

When a Root Key Holder propose a new Verifier it should provide some metadata that will be stored

The formulary to propose a new verifier needs to include this fields:

• Name/Organization
• Location
• email
• Check of available for private request
• Check of available for github assignations
• Address
• Datacap

When the root key holder push the "Propose Verifier" button, the app will send the message to the lotus node with the address and the datacap, and it will store the metadata

We need an html template to send emails to the verifiers when a user requests datacap privately

See screen shot below:

Expected would be that we capture the address of the root key holder that granted the last data cap (or modification)

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

As we recently discovered not having:

1. The latest version of ledger
2. Not having expert mode enabled

Will cause the ledger flow to not work. Is there a way of querying and surfacing these issues to a user in app?

At the least I think we can add that to the confirmation screen for the message (for the expert mode enabled) - but definitely should try and flag the ledger version thing if we can. A user won't be aware they're out of date (as I was unaware :( )

As a verifier, I will want to action the decisions I've negotiated off chain, by allocating data cap. In the current flow, I do this by choosing an address and allocating data cap to the client in question.

However, without knowing the data cap associated with an address I will have to cycle through many addresses in order to find one that still has cap remaining. Furthermore, as I spend data cap, I won't know how much I have available to me (in total) across all my addresses.

Proposal here would be to add a second column that:

1. Has a value, if a data cap is associated with the address
2. Has a NaN if no data cap associated with it

Whispers have said that in the most recent versions of lotus only t0 addresses can get a data cap.

If so, we need to ensure that we make that visible for users to verifiers such that they can request new data cap from verifiers.

Frontend app will need to push/get data to/from Github to complete the flow. We can use a Node.js framework that wraps Github API, like Probot

Depends of #20

Take a look to the different alternatives offered by Github to automate actions and respond to events

This includes:

• Feature definition
• Design
• Implementation

It is necessary to deploy some components to support the mainnet deployment. This include:

• Filecoin Registry backend (oauth bridge)
• Filecoin Github bot

To accomplish this would be necessary:

• Create AWS accounts from the root account provided by the Filecoin infrastructure team
• Dockerize the backend service
• Dockerize the github bot
• Deploy the backend service in AWS
• Deploy the bot service in AWS

Reproduction steps:

1. As a root key holder, I can confirm that my address t01066 has 3GB of data cap to allocate as a verifier
2. As a verifier, I attempt to allocate 2GB of data cap to t01046 (personal wallet)
3. I get a message successful (and a message id that disappears)
4. After waiting for a few minutes and refreshing t01046's allocated data cap has not incremented
5. After checking t01046, I can see that t01066's data cap has not decremented.
   

Deploy a lotus node (somewhere) connected to the new testnet. This lotus node will be used by the frontend app deployed on fleek

Define how the request datacap flow could be implemented using github issues, and how it can be linked to the actions needed to be executed on the verifiers tool app

Unclear the exact root cause (using a Nano X).

1. Log into app (1st address, t1y... has 9999+ YiB of data cap)
2. Copy second address (2nd address, t1x... has no data cap)
3. Attempt to verify my second address with 1TiB of data cap.
4. See screenshot

As noted here: #6

Because a bad transaction failed without sending an error back to the app, it was unclear that the transaction did not go through. We should implement proper error handling / UI displaying of those error messages in order to make it more obvious when there is an issue.

After having the bot & backend running in AWS, there are a few improvements to apply:

• The backend should run behind a load balancer and use https
• The backend should use environment variables for configuring the github credentials
• The bot should use environment variables for configuring the github verifiers
• The backend should have a proper health check
• The github bot should have a proper health check

Currently the flows designed to request datacap force clients to open new issues on GitHub that would be visible to all Filecoin community

For some kind of clients this flow could be not convenience in order to keep privacy, so it's necessary to provide an alternative that allows clients to contact a verifier privately.

On the landing page for clients onboarding the frontend app will show a tab where the users can consult a list of verifiers available to private datacap requests

The information shown will be Name/Organization, Location, datacap remained, email address

In this screen, a text will explain to the users they can contact a verifier of their choice via email, providing some information: name/organization, address, datacap, ...

The verifier will receive the email from the client, check the information provided, asking for further info if needed.

If the verifier is ok with the info provided, it will manually verify the client using the application.

Also the verifier must write back to the client to inform about the decision. If the verifier rejects the request, the client should be informed about the reason of the rejection.

The verifier is responsible to keep and custody these emails with the clients for accountability reasons. Filecoin could request this emails to audit.

Expected would be that the column header is Verified Clients

to allow to deploy different instances of the service under the same load balancer would be useful to allow to specify the root path of the service in the configuration.

also, the email service could optional depending on the config

Not high priority, but I think this would be nice from a ux consistency

The backend service must exposes and endpoint that allows to send emails using a Provider set in the configuration.
This functionality is needed to allow users to request datacap contacting a verifier directly

Definition of how the multisig governance is going to work.

• How many addresses of the multisig need to confirm?
• What is the process for adding a new rootkey?

As a result of this analysis we should have:

• Answers to the main governance questions
• Having a document describing that governance process

Ih this moment, we are using one github repo for the datacap requests, https://github.com/keyko-io/filecoin-clients-onboarding, so different networks are using this repo, mixing test issues with actual issues in the mainnet.

It would be necessary to create a new repo, filecoin-clients-onboarding-test, that replicates all the configuration and functionality to be used for testing purposes.

For this, we will need:

• Create the new repo
• Set the proper permissions
• Clone the content of the onboarding repo, including the issue template
• Deploy a new instance of the bot ( https://github.com/keyko-io/filecoin-onboarding-bot ). Maybe it will necessary to modify the bot to allow to deploy different instances in aws
• Set OAuth for frontend

Per feedback from JB, we're rebranding the name of the Verification process as well as the name of the "verifier role".

The latter is pretty much confirmed -> verifiers will be known as notaries on the network (verifier -> notary).

The former, is still being finalized.

We should update across the app to make sure we're consistent with this update!

Document the whole flow to verify a new client and allocate the requested datacap. This flow will include both onchain and offchain processes

Example: josepablofm78/TestFlows#1

As a result of this issue we should have a documentation with the flow.

Test new filecoin's testnet and check the verified clients functionality works with no issues

Right now we have localnet options - for launch we probably want to pare this down to the nodes we offer:

• Mainnet (Protofire's node)
• Testnet (tbd where this node will come from)
• Nerpanet (Riba's node)

Github - Frontend integrations

• Setup a repository for registering the datacap on-boarding requests
• Setup a new Github Oauth application
• Setup a Github group working as authorization for verifiers
• Setup a Github issue template for registering datacap resquests
• Implement in the frontend the Github login
• Fetch all the open issues from the project
• Show in a basic table the issue content + labels + nickname of the github user who opened the request
• If the user clicks the "Grant" button, remove any "state:XXX" label and add the "state:Granted" label. Close the github issue
• If the user clicks the "More Info" button, remove any "state:XXX" label and add the "state:Further info needed" label. Add a comment with some text

Provide a gist or a brief document to Filecoin team with instructions about how to configured a network from the scratch with a multisig account set for the verifreg actor

For the mainnet deployment we will need to use a proper email Provider

When iterating through your list of addresses, you need to be able to copy out the t1 address in order to send Filecoin to that address to generate a t0 address.

This is at least required when getting addresses set up, as they must be on chain to request a data cap (Verifiers will need this to get data cap from root key holders)

Repro steps:

1. Attempt to assign data cap (and approve on ledger)
2. Switched to root key holder view
3. Switched back to verifier view and attempt to assign data cap
4. Check console to see WebSocket closed error

Analyze the needs of frameworks like Textile, Slate, etc, that distributes datacap among their clients, devs, apps, whatever.
The main point to overcome, bot not the only one, is the limitation of the current implementation of the verifreg actor to renew the datacap of an already verified client.