This is the final weekly progress report for The Great Byteball Bot War. Just like the previous weeks, this one was quite busy too trying to push as much functionality as humanly possible. This week achievements:

added chat interface for passengers

added incoming payment processing

improved user feedback on certain events

main-net release (as beta)

Chatbot for passengers

In the past weeks most development effort went into building a web user interface and the underlying Byteball based payment system with smart contracts and a built in oracle. However, everyone familiar with Byteball knows that a true Byteball bot has a chat interface. One of the best features of the Byteball wallet is that it contains a fully integrated chat through which users can communicate with each other, send and request payments and smart contracts. This chat interface can be used by bots as well to expose some functionality that users can access right from the wallet.

The Byteball chat interface allows the bot developer to define custom commands that the user can conveniently execute with a single click or by typing them in. In the context of the Carpool bot these commands are:

rides - returns the list of available rides as a chat message

- returns the list of available rides as a chat message reservations - returns the list of reservations the user made

As seen above, commands such as the reserve can be sent to the user as a contextual link pre-configured with arguments for example the numeric identifier of the ride. As a result, the user can send a command to a bot by a simple click. It is a good practice to offer the user predicted follow up commands that they can easily execute without typing. Let's see what happens when a user clicks the above reserve command:

The commands reserve 22 and reservations are automatically inserted by the wallet as soon as the user clicks on the command links.

The chatbot is also used as a medium for notifications. From booking the ride to completion there are many events the users might want to get notified about. One such event is when the driver marks the ride completed. The passengers are then notified that it's their turn to complete the ride and they are shown a web url where they can complete the ride. Note, a web url is required, because that's the only way to acquire the passenger's location. Also, note the user has to be log in on the website before they can access their reservation through the web interface.

Carpooling for Byteballers BETA is live!

The Carpooling Byteball bot is now available in the main-net for anyone to try with real Byteball bytes. Please note, however, that it was developed in a very short period of time and the focus was mainly on delivering the core functionality to demonstrate a possible solution for a real life use case. There are many things to improve, especially the ride completion algorithm that is a core component in how useful this app can be in practice. In its current form it largely assumes fair usage for small carpools since one passenger has a relative large weight in voting with their location.

I encourage you to toy around with it and try it out in practice, but keep in mind bugs may occur and a payout or refund may not happen or even get stuck forever. Money is always paid in a smart contract which unlocks only if the Carpool oracle posts the completion outcome of the ride.

Brief user manual

The Carpooling for Byteballers has two roles: a driver and passengers. The creation and completion of a typical carpool is done as follows:

the driver logs in via the website, provides a payout address

the driver posts a new ride

the passenger logs in via the website or uses the chat interface, provides a refund address

the passenger reserves a seat for the ride the driver posted

the driver starts the boarding and displays the check-in QR code on his device

the passenger arrives to the pick-up location and scans the QR code with his Byteball wallet

the passenger receives a payment request and makes a payment into the offered smart contract

the driver is notified about the payment on the web UI and departs.

when they arrive at the drop-off location the driver completes the ride

the passenger receives a notification and he completes the ride as well

At this point the ride is considered finished with either a completed or incomplete status depending on the driver and passenger location. The following will happen:

the Carpool Oracle posts the completion result in the Byteball DAG

when the oracle data feed becomes stable the funds from the smart contract are sent to either the driver or the passenger depending on the value the oracle posted

Since the Carpooling for byteballers bot is a light wallet, the payout (or refund) process may take about 20 minutes or more.

Known issues