#### Repository https://github.com/byteball > After doing some quick assesment, seems I can't build this project. I will pass the ideas, direction, and architecture to the community and see if this project get move on or being stalled (probably I can only create some PoC and examples) #### Direction - Dogfooding after beta release. - Using other platforms (e.g Utopian) to submit the Task Request before beta release. - Always setup some tools to enforce many things (e.g code style, commit message, PR template, etc) early on before submiting Task Request. - Utilize frameworks if applicable. Having an agreement for convention and approach can improve maintainability. - Consensus base development? #### Technology Stack There are 3 component for creating this project: wallet, bot, and oracle. ##### Oracle This is the first time I design an Oracle service. When I think about an Oracle (not mistaken with database) I though it's a nice to have service if you already had a product but seems I mistaken. The Oracle in this project are some sort of service (Github call it App) which pass some event in Github/Gitlab to Byteball DAG. I think make it as plain as possible but well architected should be viable. | Framework and Technology | Reason | | --- | --- | | [Nest][]/[TsED][] | This is closest server-side framework I can think of which adopt many design pattern | | GraphQL | In case the Oracle need to interact with the repository. Although this Oracle will use Webhook a lot | To make it as plain as possible, I have been thinking to treat this Oracle as a switch or multiplexer. I hope this way we can avoid storing any data in the Oracle. Seems I need to detail this more in another post while demistify the flow of the data on each event. Also, having a public dashboard could be *a nice thing to have*? Maybe? ##### Bot The bot (or I should say the bot that used by the organization) is quite unique because of the plugins mechanism have an ability to install a plugin remotely. Hopefully, it can also be integrated into the wallet ⎝ ͡⎚ ͜つ ͡⎚⎠. | Main Dependencies | Reason | | --- | --- | | Apollo (GraphQL) | To interact with (and potentially combine) Github & Gitlab API using schema delegation | | Express | Have many great middleware built by the ecosystem | | Typescript | Well, this is little bit opiniated but I always though that having an ability to specify some constraints (via strong typing) can improve the maintainablity in the long term | The reasons I don't suggest to use [Nest][]/[TsED][] is the plugins mechanism that this bot has, *which mean* you need some degree of flexibility to implement your own convention. Having a rigid framework to decide the way you build this bot will limit what the plugins can do. I suggest the plugins implementation adopt how [Vue CLI 3][] and [Cerebro][] approach it by utilizing dynamic `require` and NPM registry. Ah yes, actually, the `npm` cli can be used programmatically and there is a Javascript wrapper for that, so...( ͡° ͜ʖ ͡°) [Nest]: https://nestjs.com/ [TsED]: http://tsed.io/ ##### Wallet The wallet itself is just a pretext to store and hold the token and interact with the bot to create/submit bounties. The main goal for this wallet is to be swiss-army-knife tools for managing a project, especially Open Source one (but not limited to Enterprise project). The technology stack that I'm going to propose: | Framework & Main Dependencies | Reason | | --- | --- | | Vue | To support incremental adoption of new technology via @vue/cli 3 | | Quasar | Rich UI component and community (somehow it's popular in blockchain community) | | Electron | The most known way to build and deploy desktop application. It even support native dependencies compilation which make it easy to install `sqlite3` and `secp256k1` | This wallet also has the plugins mechanism with some constraint. I suggest the plugins mechanism in this wallet borrow some extensibility principles and patterns in VSCode while the implementation adopted from [Cerebro][] which use dynamic `require` and NPM registry (I doubting about VSCode approach because it's too complex and the usage are quite different). Some constraint which borrow [VSCode extensibility patterns][] that I can think of: - The plugins API represents asynchronous operations with promises. From the plugin module, any type of promise can be returned. - Events in the plugins API are exposed as functions which the plugin creator can call with a listener-function to subscribe. - The plugins API will not expose the DOM to the plugin creator. Plugin creator can only interact on some specific UI in predefined manner. #### Architecture It's always a good thing to have a feedback when you write something. And yes, I got some feedback in my last post to use Oracle. It's quite challenging because I don't know how the Oracle usually work and after some study, here is the high level architecture that I got:

- **Desktop Wallet** - A Byteball wallet and also swiss-army-knife tools for managing a project. Can be extended via plugins. - **Bot** - From the digram above, seems the bot only act as a gateway. However, it's more than that. While it act as a gateway, it still a bot. Another role this bot has is to notify the Oracle of some user action like creating a bounty (which also deploy the smart contract). Also, thanks to the plugins mechanism you can integrate it with others services. The bot itself can also be installed inside the wallet to support developer that not belong to any organization. - **Oracle** - The Oracle service will act as a plain service (Github App). After the user authorize to use the App (Oracle), the user can controll which repository can be interacted/controlled by the Oracle. The Oracle can only do: - pass commit status update to Byteball DAG - pass Pull Request status update and metadata to the Byteball DAG - comment on an Issue or Pull Request (I take an inspiration from GitCoin) - read/set/update Milestone

Probably you (JS dev) not notice this, GraphQL query/mutation/subscription schema has similiar characteristic with Javascript Object especially when you use destructuring assignment. Both of them can pick the data you only need and also call a function inside an object (bracket). Here is the question: Is this coincidence? Do TC39 know this? Is Facebook has hidden intention? Can we convert the GraphQL query/mutation/subscription schema into Javascript expression so we can use it as a Javascript API without spin-up a HTTP server? PS: All the question is just a joke. Only the last one is the real question ᖗ👁️෴👁️ᖘ

> FYI: Gitlab GraphQL API is still alpha #### Extensibility via Plugins For the plugins system, I take inspiration from [Vue CLI 3][] and [Cerebro][] which ~~abuse~~ use NPM registry as a marketplace. And if possible, we can also adopting some of [VSCode extensibility patterns][] to make the Plugins API more flexible yet doesn't break the host (wallet & bot).

The API we want to expose can came later while developing the desktop wallet and the bot. I usually use some sort of IDL when creating 2 application/platform that share common functionality. For this project, defining the exposed API in separate repository then place it as a git submodule in wallet-repo and bot-repo could enforce both application share common API. Lastly, some potential plugins I can think of to manage OSS project: - Stackoverflow plugins - Utopian plugins - Discord plugins? [Vue CLI 3]: https://cli.vuejs.org/dev-guide/ui-api.html#ui-files [Cerebro]: https://github.com/KELiON/cerebro/blob/master/app/plugins/externalPlugins.js [VSCode extensibility patterns]: https://code.visualstudio.com/docs/extensionAPI/patterns-and-principles#_extensibility-patterns --- ^{There is repositories I create in prompt of the Use-a-thon event.
- https://github.com/git-ball
- https://gitlab.com/GitBall} --- #### GitHub Account https://github.com/DrSensor

RubyJone$ 'Same Drugs' - Self-made Visualizer