owned this note
owned this note
Published
Linked with GitHub
# Github definition / scoping
## Ressources
The oracle, comprising certain contracts and an external bot, aims to translate select GitHub metrics onto the chain, rendering them usable in our on-chain ecosystem.
While I've shared my skepticism about GitHub being the sole platform for evaluations and score/token allocations, I remain steadfast in treating GitHub as a reliable data source. It's essential we maintain its widely recognized URIs for consistency.
Elaborating further:
On-Chain Reflection of Issues and PRs: I propose that we mirror essential data from GitHub, such as titles, statuses (open, closed, merged), URIs, and some metadata. Visualize it like this:
import "gno.land/r/github"
```
issue := github.IssueByID("gnolang/gno#4242")
println(issue.Title, issue.State)
```
This allows on-chain management and tracking that's interlinked with GitHub issues. As @waymobetta and @MichaelFrazzy have been exploring similar territory, I'd like to emphasize:
- We shouldn't treat GitHub activities as direct equivalents to scores. While these metrics can guide score determinations, human oversight is vital to ensure fairness and counteract potential manipulation.
- The focus shouldn't be restricted to "merged PRs." Open issues, valuable but closed PRs, and other meaningful contributions deserve recognition.
Two-Way Data Flow: While our bot can translate GitHub activities on-chain, the opposite should be feasible too. It can monitor on-chain events and mirror these as comments on GitHub issues and PRs.
GitHub and Gno Account Linkage: As discussed, users can create a repository like github.com/<username>/.gno with a config.yml, signed with their private key. An on-chain transaction like:
`gnokey maketx gno.land/r/github -func LinkAccount -args moul -args sig(moul)`
can create a robust two-way connection, broadening our interaction possibilities, such as a bot commenting on GitHub issues/PRs.
## Proposal 1
1. **Repository Creation**
- Users will create a dedicated repository on GitHub with the following format: `github.com/<username>/.gno`
- Inside this repository, users will place a `config.yml` file containing necessary information and sign it with their private key.
example:
```yaml
functions: LinkAccount
signatures: xxx
public_key: xxxx
```
2. **User Interaction**
- When a user wants to interact with the Oracle, they can:
- **GitHub**: Comment on a Gno-related issue in the gno project.
- **Discord**: Send a specific message format in a designated Discord channel.
3. **Server Validation**
- The Gno server will monitor these interactions thenIt will parse the comments on Gno-related issues, extracting the signed `config.yml` file.
- The server will then:
- Verify the signature on the `config.yml` file to ensure authenticity.
- Validate the content of the `config.yml` for required fields and format.
4. **Data Push to Chain**
- Upon successful validation:
- The function will be excuted onto the Gno Realm.
Cons: Gno will pay the gas
```mermaid
sequenceDiagram
User ->> Server: Ask github verification
Server ->> Github: Get user gno/config.yaml
Server ->> Server: Parse to get user address
Server ->> Oracle: Push address, githubId
```
## Proposal 2
1. **Repository Creation**
- Users will create a dedicated repository on GitHub with the following format: `github.com/<username>/.gno`
- Inside this repository, users will place a `config.yml` file containing necessary information and sign it with their private key.
- Example `config.yml`:
```yaml
functions: LinkAccount
signatures: xxx
public_key: xxxx
```
2. **User Interface**
- When a user wants to interact with the Oracle, they can:
- Request the server to verify their repository and ask signature.
- Provide the necessary information such as repository URL, signed `config.yml`, and desired action.
3. **Server Validation**
- The Gno server will parse the request and validate the repository:
- It will check the provided repository URL and fetch the signed `config.yml` file.
- Verify the signature on the `config.yml` file to ensure authenticity.
- Validate the content of the `config.yml` for required fields and format.
- If the validation is successful, the server will generate a unique signature for the requested function and argument.
4. **User Interaction with the Oracle**
- The server will respond to the user with the signed function and argument, ready for execution on the Gno Realm.
- The user can then execute this function on the Gno Realm with the provided signature.
5. **Oracle**
- Upon receiving the signed function and argument from the user:
- The Gno Realm will verify the provided signature to ensure the request's authenticity.
Cons: user will pay the gas
```mermaid
sequenceDiagram
Server ->> Realm: Add Public Key
User ->> Server: Ask github verification
Server ->> Github: Get user gno/config.yaml
Server ->> Server: Parse to get user address
Server ->> User: Signature(address,githubID)
User ->> Realm: Push address,githubID, serverSignature
```
## Some sequence diagram for other flows
###
```mermaid
sequenceDiagram
User ->> Github: Comment on github
Github ->> Bot: User Comment
Bot ->> Github: Get user gno/config.yaml
Bot ->> Bot: Parse to get user address
Bot ->> Oracle: Push adress, githubId, data related to the comment
```
## Exploration