Subscribe to jShamsul
jShamsulCyberspace and Metaverse
Revisiting cyberpunk novels Neuromancer and Snow Crash in today’s context (This was first published at jshamsul.com on 2024-07-19) I remember reading both William Gibson’s Neuromancer and Neal Stephenson’s Snow Crash when I was still a teenager in the late '90s. Although Neuromancer was published much earlier, it wasn't until the late '90s that I became a fan of cyberpunk and the hacker culture, leading me to discover the novel. Neuromancer is often credited as the novel that c...
jShamsulThe Ethos of Web 2.0 and the promise of Web3
A more ideological and less technological view. (This was first published at jshamsul.com on 2024-07-23) The year was 2006. After my final year for a Bachelor’s Degree in Information Technology at University Tenaga National, several students were given the chance to pitch their final year projects to a panel of tech industry experts and venture capitalists—people who, at that time, I thought were smarter than I was. They were from Cradle, MDEC, and other supposedly industry players.Young me g...
<100 subscribers
jShamsulCyberspace and Metaverse
Revisiting cyberpunk novels Neuromancer and Snow Crash in today’s context (This was first published at jshamsul.com on 2024-07-19) I remember reading both William Gibson’s Neuromancer and Neal Stephenson’s Snow Crash when I was still a teenager in the late '90s. Although Neuromancer was published much earlier, it wasn't until the late '90s that I became a fan of cyberpunk and the hacker culture, leading me to discover the novel. Neuromancer is often credited as the novel that c...
jShamsulThe Ethos of Web 2.0 and the promise of Web3
A more ideological and less technological view. (This was first published at jshamsul.com on 2024-07-23) The year was 2006. After my final year for a Bachelor’s Degree in Information Technology at University Tenaga National, several students were given the chance to pitch their final year projects to a panel of tech industry experts and venture capitalists—people who, at that time, I thought were smarter than I was. They were from Cradle, MDEC, and other supposedly industry players.Young me g...
Subscribe to jShamsul
<100 subscribers
Share Dialog
Share Dialog
A thought experiment on decentralisations and interoperability for the e-hailing industry.
(This was first published at jshamsul.com on 2024-11-14)
Seems like e-hailing apps are popping up in Malaysia. Kummute, Lalamove, Bolt, etc…
This is all great, but one industry-disrupting game-changing feature to me would be, “interoperability”. Imagine, a passenger from app A by service A could book a ride from a driver from service B.
The passenger pays from his wallet in app A to the driver from service B, no need to download a new app, no need to top-up different wallet, rewards points are transferable, same user experience.
A more simplified example would be something like in the telco domain, a Celcom customer is able to make calls and send SMS to a Maxis customer. Networks are interoperable in this sense.
This is not impossible. A few years back, there was the “GOLD alliance” where e-hailing companies Grab (SEA), Ola (India), Lyft (US), and Didi (China) announced a partnership.
A Grab user, using the Grab app in the U.S. is able to book a ride with Lyft drivers when they are in the U.S. and vice versa. The plan was to build the same interoperability with other e-hailing providers.
The alliance did not last long. Each e-hailing company from the different countries back then had a common rival, UBER. A UBER user can use the same app when they travel in all different countries. The integration between the different e-hailing services was to offer a same value proposition to their users.
I guess, once UBER starts to either partner or merge with local providers, or leave the country completely, there is no need for the alliance anymore.
I doubt that “interoperability” is the highest priority for the e-hailing companies. In fact, it might not even be something they would want to consider. Even if they can agree on some form of “interoperability fees”, I don’t think e-hailing service providers would want to do it.
They want to keep their customers within their service, so that their driver partners can get more jobs. The e-hailing service providers do this with rewards and loyalty points for passengers, and incentive tiers and other form of bonuses for drivers.
Do we even need e-hailing companies as the intermediary? Is it possible for a pure P2P e-hailing service?
Imagine an e-hailing service that is done on a decentralised protocol. Orders and bookings are broadcasted and accepted on-chain. Smart-contracts are created to handle all the transaction stages. Cryptocurrency tokens are locked within the smart-contract throughout the journey and distributed when the journey ends.
And this blockchain is not maintained by a single business entity. Anybody could participate and run as many nodes as they want. Nodes would manage the booking broadcast, accept orders, and execute smart-contract logic. Node operators are incentivised to keep their nodes running with transaction fees from every successful booking, think of it like Ethreum gas fees.
Imagine an open, permission-less, decentralised protocol, where anybody could create an e-haling passenger app that broadcast to the blockchain a booking order, lock the passenger cryptocurrency token for the ride fees with the smart-contract. Once the ride is done, the smart-contract will release the tokens to the driver.
The same thing can be done on the driver side, anybody can create a driver app that interacts with the blockchain and the smart-contract to view and receive bookings.
I am confident that, in the technical sense, this is very much possible. However, there are real-world implications to this. There are real-world regulations that might become a challenge.
Safety for both passengers and drivers is something to think about. Since there is no single business entity that is operating it, who would the passenger or driver reach out to when there is a problem, if there is no help-center to take the complaints?
Decentralised blockchains are typically public. It is designed so that anyone can participate in keeping the network running. Every activity on the blockchain is public. Anybody can see the activity and all the transactions of any wallet address. If a particular address is associated with you, then anybody can see all your activity history on-chain. This might not be something that we would want in an e-hailing platform.
Perhaps we could meet somewhere in the middle. Not a fully decentralised network protocol, but a semi-decentralised network with multiple centralised operators.
The e-hailing service operators provide help-center support, handles KYC stuff, does the vetting of drivers, and so on. Bookings and all transaction are handled on-chain with deployed smart-contracts. Provides interoperability for users, both passengers and drivers. A passenger on the Lalamove app can get a driver on the Bolt app. A driver with the Grab app can receive bookings from passengers from the Kummute app.
Just a wild idea.
A thought experiment on decentralisations and interoperability for the e-hailing industry.
(This was first published at jshamsul.com on 2024-11-14)
Seems like e-hailing apps are popping up in Malaysia. Kummute, Lalamove, Bolt, etc…
This is all great, but one industry-disrupting game-changing feature to me would be, “interoperability”. Imagine, a passenger from app A by service A could book a ride from a driver from service B.
The passenger pays from his wallet in app A to the driver from service B, no need to download a new app, no need to top-up different wallet, rewards points are transferable, same user experience.
A more simplified example would be something like in the telco domain, a Celcom customer is able to make calls and send SMS to a Maxis customer. Networks are interoperable in this sense.
This is not impossible. A few years back, there was the “GOLD alliance” where e-hailing companies Grab (SEA), Ola (India), Lyft (US), and Didi (China) announced a partnership.
A Grab user, using the Grab app in the U.S. is able to book a ride with Lyft drivers when they are in the U.S. and vice versa. The plan was to build the same interoperability with other e-hailing providers.
The alliance did not last long. Each e-hailing company from the different countries back then had a common rival, UBER. A UBER user can use the same app when they travel in all different countries. The integration between the different e-hailing services was to offer a same value proposition to their users.
I guess, once UBER starts to either partner or merge with local providers, or leave the country completely, there is no need for the alliance anymore.
I doubt that “interoperability” is the highest priority for the e-hailing companies. In fact, it might not even be something they would want to consider. Even if they can agree on some form of “interoperability fees”, I don’t think e-hailing service providers would want to do it.
They want to keep their customers within their service, so that their driver partners can get more jobs. The e-hailing service providers do this with rewards and loyalty points for passengers, and incentive tiers and other form of bonuses for drivers.
Do we even need e-hailing companies as the intermediary? Is it possible for a pure P2P e-hailing service?
Imagine an e-hailing service that is done on a decentralised protocol. Orders and bookings are broadcasted and accepted on-chain. Smart-contracts are created to handle all the transaction stages. Cryptocurrency tokens are locked within the smart-contract throughout the journey and distributed when the journey ends.
And this blockchain is not maintained by a single business entity. Anybody could participate and run as many nodes as they want. Nodes would manage the booking broadcast, accept orders, and execute smart-contract logic. Node operators are incentivised to keep their nodes running with transaction fees from every successful booking, think of it like Ethreum gas fees.
Imagine an open, permission-less, decentralised protocol, where anybody could create an e-haling passenger app that broadcast to the blockchain a booking order, lock the passenger cryptocurrency token for the ride fees with the smart-contract. Once the ride is done, the smart-contract will release the tokens to the driver.
The same thing can be done on the driver side, anybody can create a driver app that interacts with the blockchain and the smart-contract to view and receive bookings.
I am confident that, in the technical sense, this is very much possible. However, there are real-world implications to this. There are real-world regulations that might become a challenge.
Safety for both passengers and drivers is something to think about. Since there is no single business entity that is operating it, who would the passenger or driver reach out to when there is a problem, if there is no help-center to take the complaints?
Decentralised blockchains are typically public. It is designed so that anyone can participate in keeping the network running. Every activity on the blockchain is public. Anybody can see the activity and all the transactions of any wallet address. If a particular address is associated with you, then anybody can see all your activity history on-chain. This might not be something that we would want in an e-hailing platform.
Perhaps we could meet somewhere in the middle. Not a fully decentralised network protocol, but a semi-decentralised network with multiple centralised operators.
The e-hailing service operators provide help-center support, handles KYC stuff, does the vetting of drivers, and so on. Bookings and all transaction are handled on-chain with deployed smart-contracts. Provides interoperability for users, both passengers and drivers. A passenger on the Lalamove app can get a driver on the Bolt app. A driver with the Grab app can receive bookings from passengers from the Kummute app.
Just a wild idea.
No comments yet