Super impressive to follow the progress and to learn some of the thoughts that has to go into the architecture of the solution. It's definitely a huge task to take on building a new desktop wallet, but with all the source code of the existing on ready at hand, it should be possible to extract the parts you need and add your own.
For the contract building (and actually the potential integration to external systems' APIs too) I would suggest a bot. It makes it easy for users to simply add one bot from their wallet to then have access to everything that bot offers - including connections to external APIs.
With webhooks from GitHub, it would be quite straightforward to create an Oracle that propagates various events from GitHub to the Byteball DAG too.
I really think your project is incredibly interesting and I agree there's definitely an actual demand for smooth solutions for the problem you identified.
Good luck on the further progress and keep sharing as things progresses :)
Thank you for the feedback. For the Oracle, I have a doubt if it's appropriate to forward various event from Github into Byteball DAG (I'm afraid the Oracle service got banned by Github). Maybe pass the responsibility to the organization/user if they want to deploy their own Github Oracle by themselves would be a good alternative 🤔.
@punqtured, is there any Oracle service (the open source one) which I can use as a reference?
Posting data to the DAG is pretty straight forward but to create an oracle that would post any GitHub update to the dag would probably be a quite costly approach since each transaction on the dag has a small fee.
The solution to this often is to create a subscription based oracle that will listen on the external platform's API only for updates it knows users would need.
For the use case suggested, the bot that the repository owner use to create the task bounty should also notify the oracle that it want to subscribe to that specific event. This enablea the oracle to not have to scan entire github but to focus on only one repository and probably one specific event (like the merge event) and then post that to the dag.
Another approach could be to have the bot trigger the post event. This will require one of the parties of the smart contract to ask the bot to get the oracle to post a specific piece of data. The flights delay oracle works like that. When the passenger or insurror wants to retrieve their money, they connect to the bot and ask it to post data on a given departure.
The flight insurance oracle can be found on GitHub and there's a template oracle here