New API endpoint to generate a Scorer via API (for Allo)

[Kweiss]

The allo team wants to make integrating passport into new rounds simple and easy. In an effort to streamline this process for Round Managers, we are proposing the following:

• Allo has the ability to programmatically create new Scorers based on the information it knows (Scorer name == Round name, Scorer Description will always == "Programmatically created by Allo", the wallet address will be authenticated by Allo and send in the request, the scorer ID will be sent back, we will always select the same scorer as Allo uses now (the default scorer is okay to be updated with new changes, and should be static on selection)
• the new Scorer details are returned in the response so that Allo can use the scorer in the round for the Round Manager
• The new Scorer should also show up on scorer.gitcoin.co for the Round Manager if they were to ever navigate to there.

User Story:

As a Round Manager on Allo
I want to use Gitcoin's default Passport scorer
So that I can prevent Sybil attacks on my QF round

Acceptance Criteria

GIVEN I have a whitelisted API key (Allo Key)
WHEN I submit an API request to create a new scorer
THEN I return the scorer ID as the response to the API request.

Product & Design Links:

Tech Details:

Open Questions:

• Need to ensure Allo API key can access the different scorers that are created
• Do we need to increase the number of scorers?
• Delete a scorer is not covered here... Do we want to enable deletion?

Notes/Assumptions:

[Kweiss]

Kyle needs to write another story for how we represent the newly created scorer in the scorer UI

Should confirm contract owner (round contract) is the same as the submitted wallet address by the API request.

[Kweiss]

The use case should be "Sybil Prevention" for all created scorers in this way.

[tim-schultz]

I created the endpoint passportxyz/passport-scorer#190 should fulfill the requirements without much security. I paired with @nutrina today and he suggested putting this on hold until he hears from @gravityblast or @thelostone-mc in regards to how they plan on using it from their side

[tim-schultz]

I started implementing sign in with ethereum, but am wondering if we are sure we want to use siwe as the method for protecting programmatically creating scorers? In the end the user could continually request a nonce, and submit a valid signed message and create as many scorers as they want? To mitigate this we could create an Account object for each submitted address and then enforce the 5 community limit. This is a bit confusing because in the end the round manager is going to use the allo api key to submit passports for scoring right?

One other option would be to watch the round manager factory and only allow creation of these generic scorers if the passed address has deployed a round?

[tim-schultz]

Another idea

ALLO

Given a round operator has created a round and the transaction was successful
When the round operator submits an API request to the new endpoint with the ALLO api key
Then a new scorer is created for the round operator and a scorer id is returned in the response(could also create a new account/api key and return that in response if they have a separate UI)

Passport

Given a whitelisted account submits a request to this new endpoint that includes an address that would like a generic scorer
When the scorer api validates the request and checks the logs from the allo factory contract to ensure that the provided address has successfully created a round
Then the scorer api creates a new scorer under the allo account and returns the necessary information as a response to the request

This could also be modified so that if allo wants a separate api key/account for each address they submit. The same validation would take place and the necessary objects would be created. The account id and api key could be returned as part of the response.

This would at least limit the programmatic creation of scorers and accounts to addresses that have successfully created accounts

[nutrina]

Let's run this by the allo team before resuming work on this
Have messaged @gravityblast to chat about this.

[nutrina]

@schultztimothy
Have clarified this with Allo:

• protect the API for creating a scorer only with the API Key
• make sure we have a limit on the maximum number of scorers applied
• open point: shall we have permission assigned to the API key (probably yes)? For example:
  • submit passports - set by default
  • read scores - set by default
  • create scorers

Also, an additional feature request: they wanted to be able to pass in a custom ID to be used for the scorer.
This would be a unique string that they would like to use when referencing the scorer when submitting passports for scoring or reading scores.

[tim-schultz]

This endpoint is hidden from the docs until it can be tested. Here is a sample curl to test it out. Happy to pair on using postman or help test it out

curl --location 'http://localhost:8002/registry/feature/scorer/generic' \ --header 'accept: application/json' \ --header 'X-API-Key: cR1yUhUk.EA7uhxEZD9NRNDPQ161mudv16pDTdWhn' \ --header 'Content-Type: application/json' \ --data '{ "name":"nananana", "external_scorer_id": "0x0x0x0x0x" }'