A few weeks ago, we started the process of developing task assignment models for Amara on Demand (AoD). We began by providing an FCFS prototype explained in another post, and now we would like to present the second iteration of this process: the Round Robin prototype.

As the name suggests, this prototype implements a task assignment method based on the Round Robin algorithm: Each new available translation task is automatically assigned to a linguist for a period of time during which it can be accepted or rejected. If the task is rejected or if time runs out, the task is then passed on to another linguist. The algorithm continues to iterate back and forth over each linguist until the task is accepted by one or rejected by all.

Below is a diagram featuring the technologies used in the development of this prototype:

We can see that, in this prototype, the technology stack has changed significantly.

The architecture of the prototype is detailed below:

At the blockchain level we find the Round Robin smart contract, which will serve as the application contract and will inherit a contract from Base Task Allocation. The task of this contract is to abstract common characteristics of all contracts that implement task assignment models, whether permissions, events, status variables, etc.

As with the previous prototype, we will use a database to store the Amara demo accounts and a server that will act as API proxy to connect to the Amara API and obtain information related to the tasks stored in the smart contract.

We will also use a second server, corresponding to the Transaction Manager component, that will be in charge of reassigning the tasks once their allotted time period has lapsed. This will be done through cron jobs, which will be run by sending a transaction to the contract whenever a task’s allotted period of time is up, thereby reassigning the task to a new user. The server will listen to contract events that are issued when a new job is created in order to then prepare a cron job.

The idea behind this component is to cover the costs related to these transactions. We want to spare the users (linguists) this expense, as it could severely affect the user experience and usability of the prototype. For the time being, costs will be assumed by a P2P Models Ethereum account, but in the future, an Amara account could be used to handle expenses. Another solution could be a multi-signature account controlled by the linguists themselves.

Unlike the previous prototype, we do not use ngrok to expose the servers or the frontend. Instead, we deploy them in sub-domains of P2P Models so that they are available at all times.

In order to connect with the smart contracts, we will use the Round Robin Connector, developed specifically for the prototype using Aragon Connect. As explained above, this toolkit uses the underlying protocol of The Graph to listen to and process application events. This means that our connector will need to communicate with a node in The Graph, specifically with the GraphQL endpoint, in order to query events coming from our contracts. For all this to be possible, we will need to inform The Graph node which contracts and events it must listen to and process, a task that will be done through the Round Robin Subgraph.

In this article we have mainly focused on presenting the technical specifications of this prototype, providing an overview of its components and how they are interconnected. The following articles will discuss how the new prototype is implemented and delve deeper into its new technologies and their integration.

The authorship is by Paulo J. Colombo, but this content has been made thanks to the whole P2P Models team

The designs are by Elena Martinez
The review by Genoveva López and Guerrilla Translation
Samer Hassan and Rosa Chamorro make everything possible