Development update
By Nicolas Wagner, Sam Vitello and Enrique Piqueras
We have been hard at work during the past few weeks expanding the teams and moving the product forward. We have been focused on the new front end which required new back end functionality as well as creating standards for tooling across our repos.
We are excited to share what we’ve done, show our appreciation and keep you on top of our plans.
A New User Interface
If you are familiar with Kleros, you’ll know that there are two main types of users. The arbitrators/jurors and the parties subject to arbitration (if you are “lost in translation” check out the project at kleros.io ). While developing the smart contracts and the foundations of the API, it was easier to work on one dapp that implemented the functionality required by both types of users. This process allowed us to test the entire dispute resolution flow rapidly in one place . This first POC dapp was kleros-front and was deployed at kleros.im (WIP).
Now that we are closer to finishing the MVP we have separated the two types of users into two different user interfaces. kleros-juror-front is the new user interface for jurors and is deployed at kleros.im, and arbitrable-payment-front is a simple user interface for creating arbitrable payments between two parties. In the contracting front users may create contracts between them and another party, raise disputes, pay fees, submit evidence, and all the other functionality expected from the arbitrable side. In the juror-front users are presented with a dashboard with all the functionality necessary for jurors to carry out their duties and monitor their disputes. The designs have been revamped and we have added a whole new feature set for notifications so jurors never miss a thing. We did not want the new introduced modularity to bring inconsistency, this leads us to our next announcement.
Introducing “dapper”
In 2018, it is not uncommon for the setup of a web application’s repo to take a day or two. Now, tools like create-react-app already simplify things significantly, but they still leave a lot of configuration and boilerplate for the application developer to implement. We wanted to create a more robust boilerplate built on top of create-react-app, with all the necessary dependencies for interacting with the blockchain, and react/redux best practices and patterns built in.
This is why we created dapper to serve as the base of all our front end projects. Here are some of the cool things it comes with:
- All the features of create-react-app.
- ethjs for all your web3 needs.
- A web3 bootstrapping component to make sure your users have MetaMask installed and unlocked.
- Example integration tests with web3 calls and snapshot testing using storybook’s storyshots for components.
- Pre configured Coveralls and Travis-CI.
- All the configuration you need for the above things and .scss files to work.
- Our lessdux to get rid of redux boilerplate and manage async resources painlessly.
- Our create-redux-form to create highly configurable forms from schemas with your own UI kits.
- Our kleros-scripts for standardized linting, formatting, and githooks.
Embracing Modularity (Towards The Unix Philosophy)
As we expand our projects and create more repos, we don’t want to lose consistency which is why we have created kleros-scripts to serve as the tooling standard for all our other projects. This repo will contain everything from Solidity linting scripts to pre commit githooks that use eslint, stylelint, prettier, commitlint, and commitizen.
We are always on the lookout for parts of our code that can be abstracted away into libraries for the benefit of the community, this is why we created lessdux and create-redux-form.
These projects are published on the npm registry, but are still in an early stage and we will soon add a lot more documentation for ease of adoption.
Contributions are always welcome and stay posted for a more thorough contribution guide.
A New Approach to Contract Events
One of the challenges of creating a distributed application from a UX perspective is that you have to wait for transactions to be mined on-chain whenever an action is taken by the user. In order to give users quicker responses and reduce on-chain computation, we save detailed metadata off-chain in an intermediary centralized service called kleros-store, (in the future we will use a decentralized storage service such as Swarm or IPFS for this). As the smart contract is the source of “truth” for the web application, we have to balance responsiveness/detail, (use of the store), and accuracy/reliability, (use of the chain). Note that parties still have the possibility to look directly at smart contracts or develop their own front-end would they not trust the front-end we provide.
In order to avoid race conditions or waiting long periods of time for a transaction to be confirmed before showing data to a user, Sam implemented an event listener framework that asynchronously watches the blockchain for events being triggered from our contracts and updates the store when an action is confirmed to have taken place. It can also push notifications to the frontend so users can receive real time updates. Using on-chain events as the intermediary between the blockchain and the store should improve accuracy and make the UI feel more responsive.
A Bot for Arbitrators
There are some global actions that need to be taken on the arbitrator smart contract in order to progress the state of the application. Users should not need to make these calls themselves, they should “just happen”.
To solve this, Sam created kleros-bot, which watches an arbitrator contract and takes actions, such as changing the contract period or redistributing tokens when the time is appropriate, so that the application can move along smoothly.
In the future we plan to use an on-chain decentralized solution, such as the Snow project of 1protocol.
Keep in mind that if the bot were to fail, the application would not. The bot does not have any specific privilege and users can always call these functions manually.
Documentation Updates
We have published documentation for kleros-store at kleros.io/kleros-store. It follows our specifications for saving raw files like contracts or evidence. Our partners can use this as a reference for building their own file storage provider. In the future we will be moving to a decentralized file storage provider like Swarm or IPFS.
We have been using APIDoc for kleros-store and kleros-api, and ESDoc for the other projects, but the documentation for most of them is not published yet. We will make an announcement once it is ready.
What’s next?
Our Short Term Goals
- Finish up kleros-juror-front and the required API changes.
- Make the dapps responsive.
- Improve UX, code quality and test coverage in arbitrable-payment-front.
- Test the POC or connect an existing app to our API to test the incentive structure.
Thanks to our Community
External Contributions
A big shout out to our external contributors! During the last two months we have received contributions from the following community members:
- Felippe Nardi
- Vitaly Obelensky
- Ahmed Zubair
- Rowland Ekemezie
- Eduardo Burgos
- Felix Bernabe
- Valentin Radulescu
As we appreciate good work, we have decided to increase the dev bounty to a $2,000 monthly minimum. Half of it to be paid in ETH and the other half in PNK after the first round of the upcoming token sale.
We track tasks on our github repos’ issues/projects.
We ❤️ pull requests!
If you are a Developer looking to contribute or just curious about what we are doing, take a look at our GitHub Repo and get your doubts solved on our Gitter.
Kleros is a blockchain Dispute Resolution Layer for virtually everything. It relies on game theoretic incentives for jurors to rule cases correctly. The result is a dispute resolution system that renders ultimate judgements enforced by smart contracts in a decentralized way.
Learn More
Join the community chat on Telegram
Visit our website
Read our white paper and the One -pager
Get updates on Medium
Follow us on Twitter
Join our Slack for Developers conversations
Contribute on Github
