git wallet link to nft - Githubissues

axelofwar commented 1 year ago

Started adding some framework for what I'm thinking for the contract to lib.rs - we can rework the file structure of all this stuff as I'm learning file structure in a deployment environment @0xksure. Known errors include:

github api errors (need to switch from github api to octolab after failed testing on github api client)
anchor-client errors on minting script (still learning anchor but zeroize is the issue I got to)

We would have an entrypoint that takes the github username (or the wallet address) and calls some contract functions. is_valid_pull_request and extract username would probably be the start. Somewhere in extract username we could call the mint of an nft to the wallet address from the main.rs if we want to be able to track multiple users seeking to claim the bonk rewards - or we could just keep it to username and include that in instruction data that's sent to the contract instead of using NFTs. Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR. Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made, we could do check_merge_commit and release_escrow if the check was successful. Still stuff to be fleshed out but just a high level frame before I head to bed.

I don't think it's fundamentally too different than the idea you laid out in your initial commit, I was just confused about how the relayer worked in your scope and thought it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor. We could include the add/remove relayer functions to it if we think its better that way - it'll probably be easier to make this decision after I have a better idea of how the relayer will work with the monitor as well.

0xksure commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties
A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

Skjermbilde 2023-01-13 kl 11 55 34

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with.

axelofwar commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties

A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Yeah, I basically started contract 1 and thats what I was thinking. And then in the linker we decide if we are just linking with some kind of on-chain database that makes a new pair of the original PR and the added assignee, or if we want to mint an NFT thats part of the collection tied to that PR and do it that way. I think the NFT way would be cooler and not too crazy for an mvp but depends on time and how well we can get anchor to work lol.

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

I imagined the relayer sending a instruction for requests to deposit/receive or release the escrow then in the request and release fn, we can do the handling/validation and reject the request if invalid. Don;t have to do that way but that was my initial idea.

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with. Exactly - I think if we either use the relayer to send a transaction or an instruction for the contract to create a transaction then we wouldn't need too much of a front end besides a place for the user to create their profile and link the github account + wallet to it. Could be a super simple UI that just pairs the info and sends it to the relayer if we aren't doing the NFT, or could be something cooler with wallet connect integrations etc. if we want to go the NFT route - still simple for the NFT but to leverage the NFT tech and potentially apply for more tracks.

I'll take a deeper look tomorrow - had a commit for another project I needed to make tonight and work in the AM.

0xksure commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties

A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Yeah, I basically started contract 1 and thats what I was thinking. And then in the linker we decide if we are just linking with some kind of on-chain database that makes a new pair of the original PR and the added assignee, or if we want to mint an NFT thats part of the collection tied to that PR and do it that way. I think the NFT way would be cooler and not too crazy for an mvp but depends on time and how well we can get anchor to work lol.

Yeah that's a good idea. How about naming the contracts bounty and identity/linker so it's easy to know the responsibility of each.

For the linking contract I would assume

link_account: links web2 <-> NFT. So a user could have separate @axelofwar <-> github NFT and a say axelofWar <-> Jira NFT. If rewards are earned on github it would go to the owner of the github NFT. Or a user could link plural identities to one NFT.

While the bounty program would, like you say, manage bounties and escrows. I would like place to store the list of relayers so that it's possible to give relayer(s) some privileges such as releasing the escrow. That place should probably be in the bounty program 🤔

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

I imagined the relayer sending a instruction for requests to deposit/receive or release the escrow then in the request and release fn, we can do the handling/validation and reject the request if invalid. Don;t have to do that way but that was my initial idea.

Awesome, so number 2. Then I guess we need a relayer user in the bounty. I think the BOUNTY_CREATOR would have to call create_bounty since we need the users signature to transfer to the escrow.

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with. Exactly - I think if we either use the relayer to send a transaction or an instruction for the contract to create a transaction then we wouldn't need too much of a front end besides a place for the user to create their profile and link the github account + wallet to it. Could be a super simple UI that just pairs the info and sends it to the relayer if we aren't doing the NFT, or could be something cooler with wallet connect integrations etc. if we want to go the NFT route - still simple for the NFT but to leverage the NFT tech and potentially apply for more tracks.

I'll take a deeper look tomorrow - had a commit for another project I needed to make tonight and work in the AM.

No worries, I have a better overview of how we should do things. I will just continue with the relayer and the separate contracts

axelofwar commented 1 year ago

Added some functions to the lib.rs for handling the github and username stuff from a json file instead of parsing it out of the instruction data. We can decide whether we store the json on chain and query that address as reflected in my changes or if we read it from the instruction data.

I am also still learning rust and using it in a mainnet environement, as I come from ADAS and C_++. I seem to be missing something with how to properly include crates. I am getting issues on anchor_lang as well as the cursor crate that I was trying to use to parse the raw instruction data. If you see any apparent errors with how I am using anchor @0xksure let me know. Once I solve some of these anchor errors I can try to do some better testing.

axelofwar commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties

A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Yeah, I basically started contract 1 and thats what I was thinking. And then in the linker we decide if we are just linking with some kind of on-chain database that makes a new pair of the original PR and the added assignee, or if we want to mint an NFT thats part of the collection tied to that PR and do it that way. I think the NFT way would be cooler and not too crazy for an mvp but depends on time and how well we can get anchor to work lol.

Yeah that's a good idea. How about naming the contracts bounty and identity/linker so it's easy to know the responsibility of each.

For the linking contract I would assume

link_account: links web2 <-> NFT. So a user could have separate @axelofwar <-> github NFT and a say axelofWar <-> Jira NFT. If rewards are earned on github it would go to the owner of the github NFT. Or a user could link plural identities to one NFT.

While the bounty program would, like you say, manage bounties and escrows. I would like place to store the list of relayers so that it's possible to give relayer(s) some privileges such as releasing the escrow. That place should probably be in the bounty program thinking

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

I imagined the relayer sending a instruction for requests to deposit/receive or release the escrow then in the request and release fn, we can do the handling/validation and reject the request if invalid. Don;t have to do that way but that was my initial idea.

Awesome, so number 2. Then I guess we need a relayer user in the bounty. I think the BOUNTY_CREATOR would have to call create_bounty since we need the users signature to transfer to the escrow.

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with. Exactly - I think if we either use the relayer to send a transaction or an instruction for the contract to create a transaction then we wouldn't need too much of a front end besides a place for the user to create their profile and link the github account + wallet to it. Could be a super simple UI that just pairs the info and sends it to the relayer if we aren't doing the NFT, or could be something cooler with wallet connect integrations etc. if we want to go the NFT route - still simple for the NFT but to leverage the NFT tech and potentially apply for more tracks.

I'll take a deeper look tomorrow - had a commit for another project I needed to make tonight and work in the AM.

No worries, I have a better overview of how we should do things. I will just continue with the relayer and the separate contracts

Maybe we can set up a time over this weekend to meet and walk through how we see some of these things tying together - as it sounds like we may want to include the relayer/bounty creator in this contract - then have a separate one for linking nft with various web2 profiles. Then this contract would really be interacting with the NFT and its metadata, then comparing that against the github api results - so I'm not sure where the JSON comes into play. If that's the case, the functions in this contract should probably query an nft id with respect to a collection address instead of querying the json account or parsing for the username/wallet from the instruction data.

0xksure commented 1 year ago

Added some functions to the lib.rs for handling the github and username stuff from a json file instead of parsing it out of the instruction data. We can decide whether we store the json on chain and query that address as reflected in my changes or if we read it from the instruction data.

I am also still learning rust and using it in a mainnet environement, as I come from ADAS and C_++. I seem to be missing something with how to properly include crates. I am getting issues on anchor_lang as well as the cursor crate that I was trying to use to parse the raw instruction data. If you see any apparent errors with how I am using anchor @0xksure let me know. Once I solve some of these anchor errors I can try to do some better testing.

Instead of having to parse the instruction number, accounts and data I think it would be easier and more transparent to use the anchor framework. You can check out https://www.anchor-lang.com/. This would also make it way easier to call the program and parse accounts. By splitting instructions you can also take in primitive types as input like

pub fn create_bounty<ctx: Context<CreateBounty>, domain: String, ...)-> Result<()> { ..... Result::Ok(()) }

I don't think anchor or any other framework can check the JSON on input and it could lead to errors in the program. Please check out https://github.com/sandblizzard/rewards-v1/blob/main/programs/rewards-v1/src/instructions/create_user.rs

0xksure commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties

A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Yeah, I basically started contract 1 and thats what I was thinking. And then in the linker we decide if we are just linking with some kind of on-chain database that makes a new pair of the original PR and the added assignee, or if we want to mint an NFT thats part of the collection tied to that PR and do it that way. I think the NFT way would be cooler and not too crazy for an mvp but depends on time and how well we can get anchor to work lol.

Yeah that's a good idea. How about naming the contracts bounty and identity/linker so it's easy to know the responsibility of each. For the linking contract I would assume

link_account: links web2 <-> NFT. So a user could have separate @axelofwar <-> github NFT and a say axelofWar <-> Jira NFT. If rewards are earned on github it would go to the owner of the github NFT. Or a user could link plural identities to one NFT.

While the bounty program would, like you say, manage bounties and escrows. I would like place to store the list of relayers so that it's possible to give relayer(s) some privileges such as releasing the escrow. That place should probably be in the bounty program thinking

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

I imagined the relayer sending a instruction for requests to deposit/receive or release the escrow then in the request and release fn, we can do the handling/validation and reject the request if invalid. Don;t have to do that way but that was my initial idea.

Awesome, so number 2. Then I guess we need a relayer user in the bounty. I think the BOUNTY_CREATOR would have to call create_bounty since we need the users signature to transfer to the escrow.

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with. Exactly - I think if we either use the relayer to send a transaction or an instruction for the contract to create a transaction then we wouldn't need too much of a front end besides a place for the user to create their profile and link the github account + wallet to it. Could be a super simple UI that just pairs the info and sends it to the relayer if we aren't doing the NFT, or could be something cooler with wallet connect integrations etc. if we want to go the NFT route - still simple for the NFT but to leverage the NFT tech and potentially apply for more tracks.

I'll take a deeper look tomorrow - had a commit for another project I needed to make tonight and work in the AM.

No worries, I have a better overview of how we should do things. I will just continue with the relayer and the separate contracts

Maybe we can set up a time over this weekend to meet and walk through how we see some of these things tying together - as it sounds like we may want to include the relayer/bounty creator in this contract - then have a separate one for linking nft with various web2 profiles. Then this contract would really be interacting with the NFT and its metadata, then comparing that against the github api results - so I'm not sure where the JSON comes into play. If that's the case, the functions in this contract should probably query an nft id with respect to a collection address instead of querying the json account or parsing for the username/wallet from the instruction data.

I can't this weekend, but maybe next week sometime. Which timezone are you in?

I imagine

Relayer: polls github endpoint for new PRs and issues. If there's a new PR, relay it to the bounty contract (preferably written with Anchor). This is just a continuously running server or cron job.
bounty program on Solana - contains methods like create_bounty,complete_bounty,cancel_bounty,initialize,add_relayer,remove_rrelayer
identity contract - links a web2 and web3 identity for which the web3 identity is represented as an NFT.
Simple webpage where users clicks CREATE BOUNTY and signs the create_bounty transaction. The user will be redirected here through a link that the relayer posts to the PR or issue. I think it makes sense for the User to sign transactions.

Now, the identity program can be swapped out with an existing identity program if we want. But it's smart to separate the bounty from the identity program.

What do you think?

axelofwar commented 1 year ago

Awesome @axelofwar , correct me if I'm wrong, we would have two contracts

PR, task, issue and escrowing of bounty contract that handles the state management of the bounties

A contract for linking web2 user profile and NFT. It will also be responsible for minting the NFT. The current holder of the NFT will be the bounty receiver.

So what you have started on is essentially contract 1, right?

Yeah, I basically started contract 1 and thats what I was thinking. And then in the linker we decide if we are just linking with some kind of on-chain database that makes a new pair of the original PR and the added assignee, or if we want to mint an NFT thats part of the collection tied to that PR and do it that way. I think the NFT way would be cooler and not too crazy for an mvp but depends on time and how well we can get anchor to work lol.

Yeah that's a good idea. How about naming the contracts bounty and identity/linker so it's easy to know the responsibility of each. For the linking contract I would assume

link_account: links web2 <-> NFT. So a user could have separate @axelofwar <-> github NFT and a say axelofWar <-> Jira NFT. If rewards are earned on github it would go to the owner of the github NFT. Or a user could link plural identities to one NFT.

While the bounty program would, like you say, manage bounties and escrows. I would like place to store the list of relayers so that it's possible to give relayer(s) some privileges such as releasing the escrow. That place should probably be in the bounty program thinking

Then we could do check_github_wallet and check bonk to confirm that the bonk is in the wallet attached to the username and that bonk is in the description of the PR.

Do you think we should link web2 profile (like gh profile) to a wallet or NFT? If NFT, then I guess the owner of the NFT has to pay and receive bounties. Not sure if NFT is necessary for MVP though.

Then we could do request escrow, upon receiving message from the relayer than an update to the PR has been made

So you imagine the relayer being able to pay out the bounty? Which of these Complete bounty flows do you prefer

I imagined the relayer sending a instruction for requests to deposit/receive or release the escrow then in the request and release fn, we can do the handling/validation and reject the request if invalid. Don;t have to do that way but that was my initial idea.

Awesome, so number 2. Then I guess we need a relayer user in the bounty. I think the BOUNTY_CREATOR would have to call create_bounty since we need the users signature to transfer to the escrow.

it might be better to abstract the contract that handles PR check + escrow from the relayer handling that sends messages from the monitor

If the monitor is a PR on github.com/ then I would imagine the relayer observing the monitor and either relay data to our contracts or relay a tx to a user for signing. This would essentially mean that we don't have to build a frontend that the users have to interact with. Exactly - I think if we either use the relayer to send a transaction or an instruction for the contract to create a transaction then we wouldn't need too much of a front end besides a place for the user to create their profile and link the github account + wallet to it. Could be a super simple UI that just pairs the info and sends it to the relayer if we aren't doing the NFT, or could be something cooler with wallet connect integrations etc. if we want to go the NFT route - still simple for the NFT but to leverage the NFT tech and potentially apply for more tracks.

I'll take a deeper look tomorrow - had a commit for another project I needed to make tonight and work in the AM.

No worries, I have a better overview of how we should do things. I will just continue with the relayer and the separate contracts

Maybe we can set up a time over this weekend to meet and walk through how we see some of these things tying together - as it sounds like we may want to include the relayer/bounty creator in this contract - then have a separate one for linking nft with various web2 profiles. Then this contract would really be interacting with the NFT and its metadata, then comparing that against the github api results - so I'm not sure where the JSON comes into play. If that's the case, the functions in this contract should probably query an nft id with respect to a collection address instead of querying the json account or parsing for the username/wallet from the instruction data.

I can't this weekend, but maybe next week sometime. Which timezone are you in?

I imagine

Relayer: polls github endpoint for new PRs and issues. If there's a new PR, relay it to the bounty contract (preferably written with Anchor). This is just a continuously running server or cron job.

bounty program on Solana - contains methods like create_bounty,complete_bounty,cancel_bounty,initialize,add_relayer,remove_rrelayer

identity contract - links a web2 and web3 identity for which the web3 identity is represented as an NFT.

Simple webpage where users clicks CREATE BOUNTY and signs the create_bounty transaction. The user will be redirected here through a link that the relayer posts to the PR or issue. I think it makes sense for the User to sign transactions.

Now, the identity program can be swapped out with an existing identity program if we want. But it's smart to separate the bounty from the identity program.

What do you think?

That makes sense. I imagine we would probably still need functions like

get_account_info/get_github_wallet : a function for finding the wallet address holding the nft
check_bonk : once the relayer sends the PR to the create_bounty we would still need to check that PR for bonk amount
is_valid_pull_request to make sure the pull request sent by the relayer is a valid one

I can probably move those over to the rewards_v1 contract if that makes sense and then the rest it would seem your function outlines probably cover. Request and release escrow can either be kept as their own functions and called within create_bounty & complete_bounty along with other relevant functions like is_valid_pull_request and get_account_info all of those functions can be written directly into the bounty calls.

axelofwar commented 1 year ago

Added some functions to the lib.rs for handling the github and username stuff from a json file instead of parsing it out of the instruction data. We can decide whether we store the json on chain and query that address as reflected in my changes or if we read it from the instruction data. I am also still learning rust and using it in a mainnet environement, as I come from ADAS and C_++. I seem to be missing something with how to properly include crates. I am getting issues on anchor_lang as well as the cursor crate that I was trying to use to parse the raw instruction data. If you see any apparent errors with how I am using anchor @0xksure let me know. Once I solve some of these anchor errors I can try to do some better testing.

Instead of having to parse the instruction number, accounts and data I think it would be easier and more transparent to use the anchor framework. You can check out https://www.anchor-lang.com/. This would also make it way easier to call the program and parse accounts. By splitting instructions you can also take in primitive types as input like

pub fn create_bounty<ctx: Context<CreateBounty>, domain: String, ...)-> Result<()> { ..... Result::Ok(()) }

I don't think anchor or any other framework can check the JSON on input and it could lead to errors in the program. Please check out https://github.com/sandblizzard/rewards-v1/blob/main/programs/rewards-v1/src/instructions/create_user.rs

Okay, I've never used anchor before and am still learning applying rust to solana smart contracts. I understand how create_user.rs -> user.rs -> initialize.rs -> protocol.rs. I'm still learning how you actually inherit all of these properly to fix the anchor build issues I'm having, but I get the flow. There are a lot of separated parts here and I'm still learning how they tie together.

The state files seem to be instances created at the time of instruction calls? I don't see how domain.rs plays its role.

So those are instructions because we want the resultant data to be in instructions on-chain we can send, whereas the bounty and relayer functions are on the contract that gets called by those instructions so their functions don't need to be instructions of their own?

axelofwar commented 1 year ago

After reading through create_user.rs I think it makes more sense. Still learning how we will tie these together in anchor but I'm getting the parts. Some thoughts:

Just a little confused on the seeds object and how we plan to use it. Will the REWARD_SEED be a public key address that is used to pay the signer fees? Or will that be an actual seed phrase? Also does this suggest that REWARD_SEED, aka us, would be responsible for account storage fees?
Also, the handler's ctx variable will take the instruction data and basically pass it through an identical struct in initialize which calls protocol.initialize(). So after initialize is called and works, we have a user_address = &ctx.accounts.user_account.seeds[1] and that's how seeds gets used? Or is there a different method for getting the user_address from the ctx?
Then we should have a separate function called mint_to_wallet or something like that, which is called on the user_address in the handler? Or should that be an instruction that we call and pass ctx: Context<CreateUser> through? Later if we want to find the account associated with the nft we could call the get_account_info function or something similar and have a getUser instruction that searches for the github account attached to that wallet address via instruction we sent to the contract and can return (maybe calling get_wallet or just directly return data from the instruction).

Looking through the lib.rs for the bounty contract template you have in rewards-v1/src:

All of the functions take the create user instruction as input, is that how you envision it working or as we add instructions do you see that changing? I think I'm starting to get the idea behind the way you separated some of these instructions.
Also do are we doing anything with accounts vs PDAs? I remember in my initial devnet tests this was important but haven't done anything on mainnet.

I think I'm starting to wrap my head around how all this stuff communicates a little better now. Also realizing in my haste I wasn't using Borsh. Learning 😀

0xksure commented 1 year ago

Added some functions to the lib.rs for handling the github and username stuff from a json file instead of parsing it out of the instruction data. We can decide whether we store the json on chain and query that address as reflected in my changes or if we read it from the instruction data. I am also still learning rust and using it in a mainnet environement, as I come from ADAS and C_++. I seem to be missing something with how to properly include crates. I am getting issues on anchor_lang as well as the cursor crate that I was trying to use to parse the raw instruction data. If you see any apparent errors with how I am using anchor @0xksure let me know. Once I solve some of these anchor errors I can try to do some better testing.

Instead of having to parse the instruction number, accounts and data I think it would be easier and more transparent to use the anchor framework. You can check out https://www.anchor-lang.com/. This would also make it way easier to call the program and parse accounts. By splitting instructions you can also take in primitive types as input like pub fn create_bounty<ctx: Context<CreateBounty>, domain: String, ...)-> Result<()> { ..... Result::Ok(()) } I don't think anchor or any other framework can check the JSON on input and it could lead to errors in the program. Please check out https://github.com/sandblizzard/rewards-v1/blob/main/programs/rewards-v1/src/instructions/create_user.rs

Okay, I've never used anchor before and am still learning applying rust to solana smart contracts. I understand how create_user.rs -> user.rs -> initialize.rs -> protocol.rs. I'm still learning how you actually inherit all of these properly to fix the anchor build issues I'm having, but I get the flow. There are a lot of separated parts here and I'm still learning how they tie together.

The state files seem to be instances created at the time of instruction calls? I don't see how domain.rs plays its role.

So those are instructions because we want the resultant data to be in instructions on-chain we can send, whereas the bounty and relayer functions are on the contract that gets called by those instructions so their functions don't need to be instructions of their own?

The state files wasn't finished. Will try to finish them tomorrow. So the Relayer will sign transactions and send it to an rpc that calls our programs i.e. it's off-chain. The bounty and identity program should be separate solana programs written with anchor.

0xksure commented 1 year ago

After reading through create_user.rs I think it makes more sense. Still learning how we will tie these together in anchor but I'm getting the parts. Some thoughts:

Just a little confused on the seeds object and how we plan to use it. Will the REWARD_SEED be a public key address that is used to pay the signer fees? Or will that be an actual seed phrase? Also does this suggest that REWARD_SEED, aka us, would be responsible for account storage fees?

So the seeds are just used as identifiers in the hash table on Solana. The bump makes sure that the PDA doesn't have a valid private key, so it's an account with only a PK that is controlled by the program. The payer of the fees is the payer of the transaction.

Also, the handler's ctx variable will take the instruction data and basically pass it through an identical struct in initialize which calls protocol.initialize(). So after initialize is called and works, we have a user_address = &ctx.accounts.user_account.seeds[1] and that's how seeds gets used? Or is there a different method for getting the user_address from the ctx?

Seeds are mainly used to identify accounts. So if we want to find the account later we can just use the seeds.

Then we should have a separate function called mint_to_wallet or something like that, which is called on the user_address in the handler? Or should that be an instruction that we call and pass ctx: Context<CreateUser> through? Later if we want to find the account associated with the nft we could call the get_account_info function or something similar and have a getUser instruction that searches for the github account attached to that wallet address via instruction we sent to the contract and can return (maybe calling get_wallet or just directly return data from the instruction).

We can do a cross program invocation against the metaplex contract in the create_user instruction. Or we could also mint the NFT off chain through metaplex and then pass the address to create_user. Depends a bit on how we want the NFT to be. The NFT account could use seeds which makes them easy to find later. Then we can just check the owner of the NFT as the recipient of the bounty.

Looking through the lib.rs for the bounty contract template you have in rewards-v1/src:

All of the functions take the create user instruction as input, is that how you envision it working or as we add instructions do you see that changing? I think I'm starting to get the idea behind the way you separated some of these instructions.

Sorry they are supposed to take other structs, I just put CreateUser there as a placeholder.

Also do are we doing anything with accounts vs PDAs? I remember in my initial devnet tests this was important but haven't done anything on mainnet.

We use PDAs for all the accounts in our program. None of the accounts needs a private key of their own.

I think I'm starting to wrap my head around how all this stuff communicates a little better now. Also realizing in my haste I wasn't using Borsh. Learning 😀

Hhaha, yes there is a steep learning curve involved