-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
META GitHub oracle & r/gh
#1133
Comments
Who will provide oracle service for gno.land in this case? |
It'd be really cool to have a native solution, but absolute worst case I have friends at Chainlink |
A quick update on the needs we can expect from the GitHub realm, oracle, and bot: Essentially, we require a GitHub realm for the following purposes:
|
This PR is the WIP for a both a github oracle realm and package to integrate generalized oracle functionality into realms. Wi need to clean it up a bit before it is ready for review. |
Relates to #1133 Note: the unit tests are missing from the gnorkle packages. This will not be merged without unit tests. They will be written once the design has been reviewed so no time is wasted writing and rewriting them should it be determined that structural changes need to occur. Note 2: there are two readme files included in this PR so maybe read those first. The PR is meant to be a first attempt at implementing a gno package that allows realms to integrate oracle functionality. There is a gh (github) application bundled in this PR that is an oracle and will be able to handle github handle -> gno address verification requests. Everything at the gno package (/p) level falls within a v1 path because I think this package still has a lot of room for improvements. Some things that need to be done before marking this ready for review: - [x] remove old first iteration code - [x] convert newest prototyped code from go to gno and restructure subdirectories for compatibility - [x] add more comments and doc strings - [x] create readmes - [x] add unit tests - [x] add gh verification realm tests - [x] make a way for the owner or an orkle instance to manage both instance and individual feeds' whitelists <details><summary>Contributors' checklist...</summary> - [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: Morgan <[email protected]>
Revisiting our previous discussions on the GitHub oracle idea, I'd like to delve deeper into some specifics and potential enhancements.
To recap, 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:
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 aconfig.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.
I believe refining these concepts can significantly enhance our integration and workflow.
Edit: bootstrapping foundations here: #1134
The text was updated successfully, but these errors were encountered: