[Adapter] GitHub Discussions Ownership

[mktcode]

Concept: https://octobay.github.io/docs/GOVERNANCE.html
UI Mockups: https://www.figma.com/proto/AzJ6BbBetEwtD6h6p8q1uM/Octobay-Governance-UI?scaling=scale-down

For OpenQDev/OpenQ-Contracts#7 we need a new adapter that checks ownership over a GitHub Discussion thread.

[JasperTimm]

So I've had a think about how this should work, I think the primary goal of an adapter like this should be that the discussion number referenced to create the proposal exists within the given repository. Right?

Should it matter who the owner of the discussion thread itself is? Because anyone should be able to propose and then those with standing can then create an official governance proposal from it.

We could potentially check what category it is but I'm not sure that's really necessary...

This is all assuming it's not just owners that can create official governance proposals but anyone with enough standing.

[mktcode]

Another thing to consider is, that we want a repo or org to be able to have more than just one gov token attached to it. So a simple, single repository could have two gov tokens, e.g. one for feature proposals and one for business decisions. That means, when creating a new proposal, you need to select the token (if there are more than one) which will be used to vote on it. A repo/org owner can choose between all available gov tokens, while an outside contributor can only create proposals for the token(s) he/she holds a sufficient share of.

createProposal(discussionId, voteTokenAddress, repoId, orgId = null)

Checks to perform:

• Does voteTokenAddress belong to either repoId or orgId? (lookup in TokenFactory)
  • Yes:
    • Does msg.sender have enough voteTokens? (as configured for that token, lookup in TokenFactory)
      • Yes:
        • Oracle: Does discussionId belong to repoId?
          • Yes: Create
          • No: Reject
      • No:
        • Is msg.sender registered on Octobay with a GitHub account?
          • Yes:
            • Oracle: Does GitHub account own repoId (directly or through org) AND does discussionId belong to it?
              • Yes: Create
              • No: Reject
          • No: Reject
  • No: Reject

I know it sounds weird but.... Do we even need to check whether a discussion belongs to a certain repo. What happens if it doesn't? Well... You just failed. The frontend will of course take care of this and not allow it in the first place but let's assume someone does it anyway, given that all other requirements are met of course. You see any security/abuse issues? Right now I only see our frontend saying something like "No discussion found on GitHub for this proposal.". The cost (and processing time) for creating proposals would drop dramatically without oracle calls. We should maybe also store the address of the creator of a gov token (owner will already be Octobay), so that we can check that instead of an oracle check.
And then we can also mint an NFT for creating proposals, that the creator of the gov token can give to someone else or make copies of it. By doing that, we actually don't need any oracle calls at all for those NFT holders. 🤯 The above process would of course still be the fallback if no NFT is found.

Thoughts? :D

[mktcode]

This discussion should move to the contract repo but just one more note on that:

https://nicola-attico.medium.com/erc-721-token-with-on-chain-metadata-d5e9527102cc

[JasperTimm]

So a few things:

Another thing to consider is, that we want a repo or org to be able to have more than just one gov token attached to it. So a simple, single repository could have two gov tokens, e.g. one for feature proposals and one for business decisions. That means, when creating a new proposal, you need to select the token (if there are more than one) which will be used to vote on it. A repo/org owner can choose between all available gov tokens, while an outside contributor can only create proposals for the token(s) he/she holds a sufficient share of.

I'll be honest, I feel like more than one type of token feels like an extension, considering we're trying to get everything working in this Hackathon. I'd say we should leave this til the end if we have time.

I know it sounds weird but.... Do we even need to check whether a discussion belongs to a certain repo. What happens if it doesn't? Well... You just failed. The frontend will of course take care of this and not allow it in the first place but let's assume someone does it anyway, given that all other requirements are met of course. You see any security/abuse issues? Right now I only see our frontend saying something like "No discussion found on GitHub for this proposal.".

Yeah there is a potential security hole here I think: say the current discussion is #10 it means someone can create a proposal for discussion #11, start all the voting by themselves without anyone knowing and then right before it ends they create a discussion at #11. I think it just feels icky that we don't fail on this scenarios TBH. I realise it's yet another Oracle call though.

And then we can also mint an NFT for creating proposals, that the creator of the gov token can give to someone else or make copies of it. By doing that, we actually don't need any oracle calls at all for those NFT holders. 🤯 The above process would of course still be the fallback if no NFT is found.

Hehe sure, I think messing around with NFTs could be fun. Maybe when the owner creates the gov token we can give them an 'Owner NFT', and then they have the ability to assign or revoke a 'Proposer NFT' to other registered users?

[mktcode]

I'll be honest, I feel like more than one type of token feels like an extension, considering we're trying to get everything working in this Hackathon. I'd say we should leave this til the end if we have time.

Well... sometimes it is actually more work to restrict such a feature. So I think we should just see while hacking.... if you run into a situation where you wanna actively make sure only one token can be created.... just don't. Everything else is "just" UI. But yes, let's start simple and then see how far we can take it in the end.

Yeah there is a potential security hole here I think: say the current discussion is #10 it means someone can create a proposal for discussion #11, start all the voting by themselves without anyone knowing and then right before it ends they create a discussion at #11. I think it just feels icky that we don't fail on this scenarios TBH. I realise it's yet another Oracle call though.

Should not be a problem since we work with unique and permanent Graph IDs, like MDQ6VXNlcjY3OTI1Nzg=

Hehe sure, I think messing around with NFTs could be fun. Maybe when the owner creates the gov token we can give them an 'Owner NFT', and then they have the ability to assign or revoke a 'Proposer NFT' to other registered users?

Yes, kind of. I'd love to play around with that for one day at least, to see how far we can get. Our gov token factory will hold certain properties for each launched token, like minimum required share to make proposals, minimum quorum for proposals and maybe more. An "Owner NFT" could grant access to adjust these values when needed and another NFT can bypass the "Can I make a proposal" checks. Both of them will be issued to the gov token creator and have a "clonable" flag set to true. Then the owner can decide to make copies of them and also whether these copies can create more copies or not. Codewise pretty straight forward I think. Combined with a nice UI.... could create a "wait what?" moment in our presentation. :D