Last week I write my intention that I probably going to build a way to contract/reward Contributor efficiently in developing a software-based project. In this post, I will talk about the possibles architecture that I can think of to build this kind of system. Ah yes, I'm not really familiar with the workflows of D-Apps development so any suggestion and/or critique is always welcome ( ͡ᵔ ͜ʖ ͡ᵔ )
Solution architecture level
Below is a list of the solution along with the architecture I can think of to contract/reward Contributor efficiently.
Phase -1 solution (easy)
Just open an issue, label it as good first issue + bounty and share it to many communities.
When someone makes PR related to that issue and it's being merged, ask their PayPal account and reward them.
Phase 0 architecture/solution (normal)
There is 2 best way I can think to realize it without losing the appetite to build it:
- starting and build from small things
- reinvent/rewrite something that already exists
Since I don't know the definition of small things for this problem, I will go with option 2 💩. So what I'm going to reinvent is the Byteball wallet which is based on copay. I think this is the best way for me to play around and get familiar with byteballcore and dsteem API. Basically, I'm going to build desktop wallet for Byteball with some Github and Steem related functionality/integration. I still not decided what form of integration for Github and Steem it would be, but some core functionalities that I think need to be added in this custom wallet are:
| functionality | purpose |
|---|---|
| deploy and write Smart contracts | in case the project maintainer want to set the payment condition just fo build trust |
| P2P payments in chat | in case the maintainer needs to give an extra tip |
| send Textcoins | in case the contributor doesn't have Byteball account beforehand |
For the technology stack, you probably can guess it by looking at this repo ▀̿̿Ĺ̯̿̿▀̿. Ah yes, for any electron-base-app haters out there (including mysefl 😆), I will add some productivity features that are related to managing project in Github just to justify the RAM that you are gonna sacrifice for electron. Just for info, GIMP only eat <50MB 😂
Phase 1 architecture (challenging)
This architecture are suitable if the project are runned by an organization.
Here you can see there is an additional bot that also act as an organization wallet. I'm thinking that organization bot and wallet should be self-hosted, mean that we only provide the runtime bot&wallet while managing and hosting that runtime is the organization responsibility. To make deploying runtime bot&wallet easy, we can add one-click deployment button (e.g Heroku or Azure button). The benefit for doing this is to leave the burden of maintaining and scaling that runtime into project maintainer which is the orgranization.
Phase 2 architecture (hard)
In case the desktop wallet become complex over time because the needs to add many functionality and integration, we probably need to refactor it and make plugin/add-on mechanism.
Each people probably have a different need for the feature set that available at that time so this probably can become a solution.
Phase X architecture/solution (< ━╤デ╦︻(▀̿̿Ĺ̯̿̿▀̿ ̿) }})
Oracle Service
Well, this is a whole different subject. The idea is about to have distributed CI that incentify some people that share their machine to be used by the community. Some CI service I know that have this functionality is Gitlab CI. You can install Gitlab CI runner and share the machine you have to the rest of the world to run automation build/test that are from public repository. Those service are crucial for open source development, especially if it involved microncontroller, single-board computer, or GPU. However, it's not free for project hosted in Github plus it doesn't incentify the man who share his machines to run automation build/test from other repos. As a proof that this is important, you can do some quick survey on how many Arduino library out there that are well tested 😢.
This conclude my progress in #byteball #useathon with some insights, ideas, and unnecessary ranting 😋. Hope you enjoy 😂.
Hi @drsensor!
UA account score is currently 1.480 which ranks you at #36111 across all Steem accounts.
Your rank has dropped 59 places in the last three days (Your UA has decreased by 0.000).Your post was upvoted by @steem-ua, new Steem dApp, using UserAuthority for algorithmic post curation! Your
In our last Algorithmic Curation Round, consisting of 161 contributions, your post is ranked at #150.
Evaluation of your UA score:
Feel free to join our @steem-ua Discord server
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