Web: standardbounties: automatically cross-process bounties posted to bounties.network to gitcoin

[owocki]

acceptance criteria: automatically cross-process bounties posted to bounties.network to gitcoin

[owocki]

@mbeacom @jasonrhaas either of you want to take this on next? i feel like it's an important piece of scope that we missed in v1

[mbeylin]

The low hanging fruit implementation of this would be allowing the Gitcoin app to support fulfillments which are submitted on the Bounties Network, and allow bounty creators to accept them. This means that non-code bounties can have deliverables which aren't given on a github repo, but through other formats (files, links).

[jasonrhaas]

The question I have is: Do we want all the bounties posted on bounties.network to show up in Gitcoin? Or should there be some kind of Gitcoin Tag on the bounties.network post that shows it as a Gitcoin task? We can use the meta.schema field that we set up in IPFS for that.

[owocki]

maybe initially we just filter through and process ones that adhere to the gitcoin schema...

it it could be built such that it was extensible to other schemas.. thatd be 🌮

[mbeylin]

To add, when bounties are created on BN we let users select one of several categories, and the 2 related to gitcoin are code and bugs. These are also the only bounties on BN which will ask users to input a github url (stored as adheres to the schema). My advice would be to support bounties which include either the code or bugs keyword, with a github URL which matches Gitcoin's platform (i.e. a url that links to a github issue).

[jasonrhaas]

So when a new bounty is created on BN, what will the meta data be? Will the platform still be bountiesNetwork or will it be Gitcoin? In other words, when Gitcoin is looking for bounties, should it look for the keywords as you say? Or just the meta.platform? If we do the latter than it is on BN to determine that issue applies to Gitcoin.

  meta: {
    platform: // a string representing the original posting platform (ie 'gitcoin')
    schemaVersion: // a string representing the version number (ie '0.1')
    schemaName: // a string representing the name of the schema (ie 'standardSchema' or 'gitcoinSchema')
  }

In terms of implementation, I suppose we would need some kind of micro service to:

• Listen for new transactions on the Standard Bounties contract
• Determine if it applies to Gitcoin. Whether by keyword or meta.platform.
• Run the sync_web3() function on Gitcoin to update the database with the data from the contract/IPFS

[mbeylin]

currently when bounties are created, the meta is:

meta: {
                platform: 'bounties-network',
                schemaVersion: '0.1',
                schemaName: 'standardSchema'
              }

Otherwise your described plan of attack seems very on-point to me.

[jasonrhaas]

I'm envisioning this being a small python service, that "scrapes" web3 for new transactions, and grabs data from IPFS. If it applies to Gitcoin, it would call the sync_web3 endpoint to create the new issue.

Viable approaches might be:

• Micro service running python (python web3 and ipfs)
• Add method to helpers.py directly that does this (all in python), and run a cron job that checks web3 on some regular interval
• Micro service running node.js (javascript web3 and ipfs)

Probably the best approach, but also the most work is this:

• Establish an API or webhook for publishing bounties to Gitcoin

If we plan on integrating other platforms besides just BN, it might be easiest to provide users with a "webhook" endpoint. So they can do a POST to Gitcoin with the relevant Transaction Hash for example. Gitcoin receives that hash, and looks up the rest using web3 and IPFS. This could be a micro service that just listens for the request, and acts appropriately.

[owocki]

we could maybe be combined with https://github.com/gitcoinco/web/issues/128 -- two birds, one stone!

[owocki]

it might be easiest to provide users with a "webhook" endpoint.

i could see this as a management command too.. there's already the bones of this in the sync_geth.py management command

[jasonrhaas]

Doing this as a management command might be the path of least resistance. So the command would run every so often and check for new data in web3, also looking for new standard bounties and then sync'ing with the database.

[owocki]

So the command would run every so often and check for new data in web3

yep... or i think web3py also has a persistent listening command we could just have as a persistent background job.

[owocki]

im gonna start on https://github.com/gitcoinco/web/issues/128 tomorrow

[owocki]

done!