Dissecting MONET Use Cases: User-Centric Application for P2P Ride Sharing

Introduction

In previous articles, we described MONET ecosystem and the role that TENOM token would play in it. We’ve received a positive review of Babble consensus, but no technology should exist just for the sake of itself. We’ve outlined the types of use cases MONET is good for. The examples of sharing economy are numerous: transportation, delivery, housing, payments, networking, services, learning, just to name a few.

We are building MONET with a mission to create an open-source infrastructure for truly decentralized mobile peer-to-peer applications. Hence, we are industry agnostic and make the ecosystem versatile and robust to accommodate a broad variety of sharing economy use cases on mobile.

In general, MONET tools and ecosystem are best suited for frequent, standard, and repeatable interactions, finite in time, with a clear outcome, and with participants in geographical proximity. In these cases, a participant interacts within the boundaries of a specific community, driven by a specific goal, and takes on a role that does not change over the course of the interaction. Ride sharing, for example, fits well in this concept. The very nature of this activity makes it more convenient to be executed on mobile and requires multiple participants that are either riders or drivers.

On the other hand, applications with variable tasks under one roof and applications that last extensive time or only have one participant are probably not the best use case for MONET ecosystem. Single participant applications, like productivity tools, do not involve interaction with others. Applications with variable tasks (think of Jira for a project management and Trello for event preparation) would probably require breaking a large task into a small simple steps, around which an interaction occurs within a temporary blockchain. Long lasting interactions would not need the temporary nature of MONET blockchains (think social media, like Instagram). In these cases, MONET might not deliver a lot of immediate practical advantages (if you view otherwise — we welcome your thoughts!).

Now that we are clear on the general formats of interactions MONET is suitable for, let’s look at a specific case.

Decentralized Peer-to-Peer Ride Sharing

To give the community a better idea of the types of DApps we envision being built on Babble, in this article, we wanted to apply the MONET ecosystem to a specific case familiar to all of us, ride sharing. We will examine the status quo and problems with it. Then, we’ll look at how MONET can transform the ride sharing industry, creating new incentives both for drivers and for app developers.

It is important to qualify, however, that our vision describes only one possible configuration of this use case. It’s not a prescription or a single right way MONET can be used in the applications of this type. We are happy to learn others’ thoughts of possible ways to execute the idea.

Status Quo

You go out on a Friday night and need to get to your friend’s house. What’s the first name that comes to mind when you think of taking a cab? Uber, of course. Getting a cab without having to hail it on the street or calling a number and repeating the address many times in hopes that the operator gets it right has changed our lives. It captured a vibrant economy, giving the riders convenience and drivers — additional income.

Of course, Uber is not without a flaw. Exploiting some of the Uber’s disadvantages (like the large commissions Uber takes from a fare and driver’s inability to see the destination, which can lead him to remote areas he’d rather not drive to) other alternatives have come to life. Take ViaVan that offered shared rides only within specific, relatively small, areas in busy cities (e.g. Zone 1 and Zone 2 in London) for a small fare. Letting drivers navigate the popular routes in congested areas, the idea was to improve the traffic situation and to enable the drivers to make money on the sheer volume of the small rides.

Appearance of the likes of ViaVan represents attempts to further democratize the cab riding industry. Ask any driver, and they almost certainly will tell you that they use a number of taxi apps to derive their income. It is a long way to go before we can say that these apps are fully giving power to their users. As long as there are more convenient / cheaper / user friendly alternatives, the participants of this economy will explore the alternatives.

Vision: a User-Centric Ride Sharing Application in Distributed P2P Environment

Tweaking different variables, like app commission, ride pricing, available areas, all allow changing a degree to which the app developers care about the users vs about the bottom line. In today’s world, maintaining such an ecosystem is a costly enterprise. Given the number of operations these apps are expected to perform, the server costs are a sizable chunk of the budget. So, it is not unfair that, to enjoy the convenience of the app, one needs to play by its rules and also give up a large amount of personal data (like card information and geolocation).

MONET, providing an ecosystem to create serverless applications, cuts developers’ expenses on servers and allows them to create with a user-centric approach in mind. That means a DApp can have enough of a flexibility to allow its users to decide: what areas to operate in and what prices to charge. Let’s call the ride sharing DApp built on MONET infrastructure a “Babble Ride.”

In a centralized setup, such as ViaVan, a business strategy may not support expansion to Zones 3 and 4 in London. It also may take ViaVan tons of dollars and months of research time to find other zones that would make business sense. In Babble Ride, a driver, who knows a specific busy route, can define his own zone, as long as its density justifies the prices the driver charges. In this scenario, the supply and demand of the rides (and not the business strategy of a company) determine livability of a chosen area.

A user-centric approach in combination with the ability to scale without huge server budgets allow implementing business models that benefit both drivers and app developers while keeping the prices affordable for the riders. If Babble Ride requires smaller server expenses, it may enable its developers to explore a variety of business models: charge drivers a smaller commission for the rides, charge a fixed amount per a successful ride, let go of commission at all and charge a subscription fee, implement advertising, etc. All of that can exist while giving the price-setting power entirely to a driver.

Babble Ride Setup

In Babble Ride, the app itself does not constrain the drivers where they perform their rides. A driver, observing an area with good opportunities, launches a zone, initiating a temporary ad-hoc blockchain that others, both drivers and riders, can join. Supply and demand for rides determine the depth of this micro marketplace and how long the temporary blockchain lives in time.

Meet Jane, a college student who lives in a dorm. Her main campus is two miles away from the dorm, and four times a week she needs to get to classes early in the morning. That generally would make a commute a nightmare, but luckily, in exchange for a promise to visit her family on holidays, she got a Toyota Prius.

An entrepreneurial spirit, Jane offered some of her dorm mates a ride to campus to cover parking expenses and gas. She tried sharing the ride info on posters, creating spreadsheets, sending calendar invites and notifications via messengers. To her disappointment, though, at times she would ride empty only to get a text from someone she barely knows that she missed her by a minute. At other times, she would need to say “No” to the whole bunch of requests and stuff her buddies into her Prius like sardines in a can.

Jane does not look at her driving gig as potential career, but she does depend on the money she can make from these rides. The hassle of becoming an Uber driver does not fit her student goals. If she wants that extra income, she is stuck with the frustration of managing her dorm mates’ plans… Until she discovers Babble Ride.

With Babble Ride, Jane initiates a new blockchain (on which she is the first node) and registers it on the MONET Hub, where other people can discover it. Potential passengers and drivers in the vicinity, can see on the MONET Hub that an ad hoc ride sharing community is popping up in their area. They can request to join this blockchain and participate in the gossip protocol with Jane and other members (distributed consensus) to find and organize rides. The blockchain replaces the expensive central servers that usually takes care of coordinating drivers with users and empowers this autonomous community with an efficient and secure coordination mechanism.

Jane gets Uber-style comfort and ease of operations, but with no time/money sacrifice required to become a part of the popular service. Her co-riders pay her right in the app.

People come and go from this blockchain, but the information about the ride, including the rave reviews her happy riders leave for Jane, could be safely persisted in the MONET Hub so that next day, next week, of next semester other riders can discover someone in their community, who delivers real value!

It turns out, Jane spotted a busy area really well. As more and more passengers and drivers join her ad hoc blockchain, discovering it on MONET Hub, this community gains more and more value. Now all the requests that Jane could not fill with her Toyota are accepted by other drivers that joined the zone. The drivers’ supply grows as long as there is demand for more rides, and vice versa.

And for Jane, she covers her gas and parking, picks up a Saturday when she drives her dorm mates to and from a nearby grocery shop, and makes something extra to spend on herself.

Bring It Back to Earth

We outlined how MONET can power peer-to-peer ride sharing within a tightly knit community with rules and terms defined by the participants of this community. The whole interaction is started, executed, and finished on off-the-shelf mobile devices, which for the period of interaction become the full nodes on a temporary blockchain.

A temporary blockchain can form around a specific area that a local community spots. It can also form around an event that drives a lot of activity to an area (think World Cup in Russian cities).

It should be noted, however, that the cab industry is a complex one and creating a serverless ride sharing DApp is not a trivial task. Many counter-arguments and practical concerns may arise executing this idea. We, at MONET team, will leave it for the people with a domain expertise to find specific solutions for each matter. However, a brief discussion of assumptions behind the idea and acknowledgment of certain nuances may be a helpful way to demonstrate the flexibility of the MONET ecosystem.

The user-centric approach, where drivers determine zones where they operate and prices that they charge, assumes rationality of users. Of course, there is no expectation that a car owner in a suburban area would be able to fill up his schedule with short rides and charge whatever prices he desires. That means the user-centricity assumes that a driver would understand which areas are reasonable to open new zones and what prices make sense to charge. And it is not unreasonable: from within a local community people can spot a hot driving area faster than from a boardroom of a startup in a big city.

The temporary blockchains assume a level of cooperation between participants, since service providers join blockchains started by other drivers. The Babble Ride developers can determine whether they reward a driver who initiated a temporary blockchain that others can join or remove any benefits of being the first to start a blockchain. There needs to be no perception by the temporary blockchain initiator that other drivers in the area destroy his monopoly by joining it. Neither a presence of a temporary blockchain in an area should stop a new driver from joining it as opposed to launching his own. The incentives that can potentially resolve this are up for the app developers (and game theorists among them) to determine.

The serverless setup and the truly decentralized nature does not relieve an app developer from having to do business development and spend on marketing. Though we can assume that both riders and drivers are generally open to Uber alternatives, the go-to-market strategy for our hypothetical Babble Ride should nurture virality and balance supply and demand from the start. In other words, just because it’s decentralized, rides’ and drivers’ availability is still crucial and those will not appear on the DApp out of nowhere.

Decentralized architecture may not be immune to regulatory environment changes and lobbyist pressures. Just like a strategy to build awareness, the need to navigate the regulatory environment does not disappear with architectural changes. Even though the idea behind creating a DApp is always an ignition of an ecosystem that would become autonomous from its creators, the fact that the taxi industry is highly regulated and protected by the incumbents cannot be ignored by those who set on creating such DApp.

The temporary nature of the blockchain raises personal safety questions, which are difficult to resolve in a fully decentralized way. While Uber ensures that drivers have some experience, implementing driver approval in Babble Ride would mean less decentralization. Some reputational system would need to be in place to allow riders to trust the driver with their safety. Even though the blockchains serving new zones are ephemeral, it cannot mean that it would correspond to a different driver ID for each new blockchain. MONET Hub can be the key to persisted reputational record, whereby what happened on one blockchain (reviews for a ride from dorm to college on Monday) can be proved on the other (a ride from dorm to grocery shop on Saturday).

If token becomes a means of payment for a ride, the need to incorporate an exchange to use the DApp introduces significant transactional expenses and volatility risks. We mentioned in our previous posts that DApp developers are not required to use TENOM as a payment means. They can incorporate payment methods they prefer, including fiat, unless the Babble Ride DApp developers decide that they want their users to live in a fully tokenized economy. Otherwise the DApp can be executed in a way, such that a lay user would never have to be aware or understand blockchain at all.

What’s Next

At MONET, we want to power sharing economy on mobile by creating an infrastructure to deploy applications for frequent, standard, and repeatable interactions, with finite time and a clear outcome. We want to knit closer the individuals within specific local communities by letting them interact and get things done quickly and without sharing their data. We want to provide developers with new tools to let them explore new business models, challenge incumbents, and serve the causes they care about.

The use case outlined above may be developed further, transformed, and improved. What has started as an additional income for an entrepreneurial student may turn into a way to access school in rural areas or a means to travel to new job opportunities that were out of reach before.

The ride sharing case can be extrapolated to grocery delivery within a community, neighborhood fund pools for joint renovations or events, dog walking, cat sitting, and many more!

We invite inquisitive minds to explore the various powers of peer-to-peer ride sharing economy and how these powers can be amplified by using the tools we are developing at MONET.

Share your thoughts on our Telegram: https://t.me/MonetNetwork