Carpooling for Byteballers - The Great Byteball Bot War, week 2

This is the second week of The Great Byteball Bot War, a lot of coding was done in the past couple of days, lots of new features added, let's get into it. The main effort went into creating the user interface and the fundamental user interactions. I like to start with building the GUI first because that helps making quick prototypes and I can see the flaws of my initial ideas much quicker. At that point it's easier to fix things and reconsider what needs to be changed. Now read on, but don't forget to check out the test site at https://carpool-test.byteball.market/. Remember, it runs on the testnet so you need a testnet wallet to log in and see all features.

Improved authentication

Last week a quick integration was made with the byteball wallet that let users authenticate themselves by simply scanning a QR code. This week I also added log out functionality and also a display of the name of the connecting device (wallet).
Connecting the wallet is essential for using the application since it allows me to create smart contracts, ask for attested profiles and in general communicate the user through the chat interface of the wallet.

Added UI to create a new ride

Authenticated users can now post new rides through the web interface. The entered pick-up and drop-off addresses are translated to geo coordinates using Google Maps API and saved only if they are valid addresses. It's been a while I had to use Google APIs and this time I was shocked to realize they changed pricing. One innocent call to their geocoding API and they charge you by $0.005. That's $5 per 1000 request! Fortunately there is still a free tier so every month you start with a $200 credit which is 40000 free requests a month. For a small site that's quite ok, but an app with more traffic can quickly make you broke especially if you use it in combination with other map APIs. As an alternative, Mapbox could be used instead of Google Maps which offers an about 10 times cheaper solution.

Listing upcoming rides

Last week only a mock-up was created for the carpool bulletin board. This week I put database and rest API under it, so rides created are persisted in the database and listed immediately. The listing displays the addresses and the available seats and a link to Google Maps showing the directions from the pick-up location to the drop-off. In addition to that, it also hosts two user actions: making a reservation and start boarding for the ride. See next sections.

Making a reservation

From week 2, it is now possible to sign up for a ride by simply clicking the Reserve button. You cannot cancel it though at he moment :) so only press it if you really wanna book a place with that carpool. At the time of the reservation no payment has to be made, although I am thinking it would make sense to at least put a deposit of some sort in a smart contract that could be withdrawn let's say 24h before departure, but not later than that.

Start boarding

I was also able to implement the boarding process. It is actually strikingly cool and is a smooth experience for users. I added a boarding step because that confirms the identity of the user on site, so the driver can be sure that the person that is about to sit in the car is actually the one who made the reservation. Of course, only users who have reservation can check-in. This is how it works:

• driver starts the boarding process which displays a check-in QR code
• a passenger arrives and simply scans that code with his or her Byteball wallet
• magic happens behind the scenes and the driver is notified right away who checked in

You may wonder how this works. Scanning a QR code with the Byteball wallet allows you to check-in? What the heck? Yes, it is possible. The procedure is quite similar to the login flow. The displayed check-in QR code is in fact a special Byteball device pairing code that identifies the specific ride that started boarding. When the user scans the code, his wallet triggers a pairing process with the carpooling bot. The bot receives the pairing secret from the user and voila, we have a connection that pairs a user to a ride. Through a web socket connection this event is pushed to the driver's web browser which displays the checked in user. It would be possible to send a notification to the driver via the Byteball wallet as well, but for now I consider the web UI as the main interface.

Known issues

• When entering an invalid address that cannot be geocoded, Google Maps API hangs for a minute or two until it times out. Not sure why.

What's next

There is a couple of routes to continue with the project:

• add some chat interface to search and reserve rides so users could do that right from the wallet
• add names to user accounts using real name attested profiles so the names of the driver and passengers could be displayed instead of device addresses.
• implement smart contract to pay for the ride

I haven't decided yet how to continue, stay tuned till next week when I write up week 3 progress report!

Until then, happy holidays!