What would a decentralised Uber look like?
shkspr.mobi
shkspr.mobi
Why? Because I'm very annoyed at postmates/uber eats, doordash, and grubhub. At my fiancee's place, there is a restaurant we love. Neither we, nor the restaurant moved, and yet postmates suddenly claims that it is now "too far to deliver". The restaurant is on doordash, but they gatekeep the menu, and basically none of the restaurant's menu is available except for soda and extra napkins. The place isn't even on grubhub. There are many more places like that. I've placed orders for pickup and round-trip uber'ed to get them, but that's a huge waste of time.
What I want is a service where if I place an order myself for pickup, I can book a courier to get the food for me. Please tell me somebody is working on this.
Uber has a package delivery option. That actually sounds interesting. I may try that the next time we're at her place.
A decentralized uber - just like a gig economy uber - cannot benefit from pooling leases, cannot benefit from pooling insurance and as a result has a higher cost basis than a taxi service. People will take the cheapest option when a service is a commodity.
This is just as true of food delivery.
Decentralization has no inherent value to a customer beyond the ideological. Stop decentralizing things for its own sake and start focusing on the economics.
It's quite simply not financially lucrative enough to run a utility for venture capitalists. In a more sane, less inflated economic climate, this might change.
If you're drunk then maybe you should have planned ahead. Or just heat up a frozen pizza.
Perhaps stop making excuses for being hapless.
It makes more sense to me for the restaurant to validate their own team of couriers, so what you really need is a company that builds a widget which allows restaurants to cheaply host a grubhub/doordash equivalent on their own. They just need some super low-code no friction solution because restaurants can be pretty tech averse. You would need to really figure out what the killer features of grubhub/doordash are and how to put those in the hands of the restaurant, I imagine the 20+% cut that grubhub takes would make it an easy sell.
A system where restaurants take responsibility for deliveries is in principle decentralized as well, but I would argue that being a restaurant and managing deliveries are generally different tasks. Without other controls that system would likely devolve to one central firm contracting our delivery workers to restaurants, which is essentially exactly what we have now.
The issue with worker protection is not really about the size of the organization, but about who has control and decision making power. I suppose I should have said a cooperative of delivery drivers instead of a union, because in the USA the Taft-Hartley act severely compromised how unions behave and centralized their power in union leadership. So that was my mistake in phrasing.
But I believe a cooperatively run delivery service would better look out for the rights of delivery drivers specifically, compared to restaurants who are more focused on managing food service and would be likely to subcontract delivery service to a centralized firm.
Or look we have it both ways and restaurants subcontract to a cooperative of delivery drivers. My point is delivery drivers should organize and collectively manage their jobs. Actually I think every firm in our economy should be a cooperative.
What are some reasons a restaurant owner would not want their restaurant on GrubHub (let alone their listing as fleshed out/optimized/detailed as possible)?
They're either too busy or they're deliberately ignoring it/avoiding it for ______ reasons (they don't want the headache that comes with "grubhub" style customers/orders/confusion?)
The thing that is very hard to replicate is that Uber provides a form of insurance and moderation, where human operators can choose to refund for cancelled rides in situations where it is tricky to determine who is at fault.
They are also able to do it optimistically, refunding people and then adjusting policies if it turns out the policies are being abused. This stuff is very hard to encode into a decentralized protocol.
Whats the nexus between centralization and ability to refund? Regardless of centralization i can cancel my credit card to stop you from clawing back an optimistic refund, regardless of centralization the protocol could force a waiting period before withdrawing optimistically refunded monies, etc.
You're exactly right --and there are some ways to solve the problem while remaining decentralized.
The ideas you bring up are, essentially: credit, insurance, risk, reputation.
Tracking reputation on-chain is workable, and already exists. For instance, some airdrops have been done based on on-chain activity and reputation. Decentralized founders wanted to reward those with "good on-chain behavior."
The way I imagine this would work for a decentralized Uber:
- Pay for fares on-chain (ideally, a 2nd or 3rd layer, e.g. a ZK rollup)
- Drivers rate users on-chain, using the payment address
- Possibly use other on-chain information to form a "credit/reputation profile"
To protect privacy, we'd need to take extra care to shield user info (using e.g. ZK proofs), or just make everything completely transparent. It's also possible to use privacy for the payments/assets system, and make the reputation system transparent.
I do not think we'd want to be storing ride data, etc. on-chain. I'd look into something like OrbitDB, or some other decentralized system that's meant to be a database.
The world looks quite different when a significant proportion of the population are significantly stronger than you - strong enough that you couldn't physically stop them doing horrible things to you.
Uber with random drivers is sketchy, but you know there's been at least minimal background checks, and knowing that Uber are tracking the ride gives a bit more safety.
> who claims to own blockchain address X
Ownership of a blockchain address can be proven with a signature.
In the current system, I've never had a taxi driver prove they are the person registered to drive that particular taxi.
How? If my friend gives me their passcode / phone / Token, I can impersonate them.
If the private keys were stolen then a malicious person could impersonate your friend and act badly. Similarly, in the current system, a person can pretend to be a taxi driver and act badly.
The app leverages the ONDC protocol and Beckn [2]. There are technical talks on it by the founder of Beckn who was also the architect of Aadhar which is India's Biometric identity system. Beckn was also cofounded by the founder of UPI, which is India's digital payment system and currently the largest in the world. Great Video explainer on Beckn [3].
[1] https://www.ft.com/content/b1bc25c5-43c8-458d-bdc3-ab66c7cb5... / https://www.youtube.com/watch?v=3oedj_fGXAs
The only time you need blockchain ever, is for censorship/government resistance; and e.g. "decentralised Uber" could literally be done municipally. Strikes me as a good government use case.
For riders, not having to locate and setup the service is going to matter at least some of the time, and is not well addressed by local systems.
I don't think blockchain is likely to be the answer either. It adds enough complexity that things anyway end up "centralized" in the primary implementation of the system, so you might as well directly implement something that isn't all turned inside out to enable blockchain storage.
The thing that they solve well is incentivizing people to operate a network, and doing so with security properties that are different from centralized networks. In the case of "decentralised Uber", that would look like an Uber network that continued working even if some subset of participants became evil or disappeared. With sometime like Bitcoin for example, you could shift the security property from "network behaves correctly as long as the local government is honest and online" to "network behaves correctly as long as >50% of hash power is honest and >X% of hashpower is online"
It's not really about censorship and only a tiny bit about government resistance. It's more about not trusting anyone. My personal take is that some trust is good for an uber-like product, so current-gen blockchain solution would be worse than actual Uber.
As for your first statement; exactly, and to me this sort of shows the limited thinking of many "into blockchain" people. Bitcoin and money is a pretty good use-case, and I can think of maybe a few others.
But, local government control of some local things works extremely well in a lot of cases, and I can see no reason why it couldn't for an uber/doordash replacement.
In the ride share situation, the need for identification and reputation scoring is probably overrated. We flagged taxis and paid cash for a hundred years with little problems. I have hitchhiked all over the world for years and never had any real problem. Some safety mechanism should be in place for more vulnerable people. The app would know the license plate and make of car, and a button on the app clicked a few times could dispatch police using GPS. This would make it safer than walking down a street. The driver would have similar emergency button that sent all the relevant information via 911 channel.
It may not yet be time to launch this, but the existing ride share duopoly will be facing more problems ahead in financing and regulation that will eventually make this alternative very appealing.
I don't think that at all. Reputation systems strongly discourage bad actors from joining the system. Look at email spam for the importance of reputation in distributed systems, and then consider that people are risking auto accidents, being the victim of a violent crime, or being scammed.
In my home town, rogue taxis are a big problem. Not with robbery usually; but with rigged meters, not using a meter, deliberate detours, picking up extra customers along the way, harassment against women, cheating pocket money out of child, etc.
Those were surprisingly rampant especially at airports and train stations because tourists typically don’t know what price/time to expect. The amount of deception is frankly speaking, staggering.
Centralized apps, with a relatively transparent quote beforehand, a map and route in the customer’s hand, largely solved this problem.
It also seemed to have improved the average tidiness, given that it’s part of the rating. It used to be that the drivers would happily smoke in your face even if there are children or pregnant parent.
This is just one city of course. I don’t presume that every city was infested with horrible taxi drivers like where I come from. But to me, “with little problem” is not how I’d characterize the taxi business of the past.
The taxi companies in my hometown don't give a flying toss about complaints.
The customer essentially has no power of making an informed choice when it comes to picking a driver. A driver might have been complained about 800 times in the last year, but you can't know that, and therefore it can't be used against the driver.
A frequently complained driver brings the same amount of money to the company as a well-behaved one, so as long as they don't cause any legal trouble, the companies don't care and don't act.
But how? Amazon's strength in the retail is their own automated warehouses, their own fleet of delivery vehicles, and various agreements with shippers and larger-scale producers of goods. It all benefits from scale, and not from decentralization into a network of independent nodes.
What's important is that "local" seems to have gotten lost in the shuffle. Food delivery companies charge fees like they are introducing me to restaurants I have known about for years. But since there is not a "local internet" it's all the same.
It's only tech purists who want decentralized services. Nobody else does. It doesn't solve any problem actual people have. It's why everything is cetralized. That's not an accident. It's not a market failure.
- Hailing via an app.
- Cost negotiated upfront.
- Reputation system.
Without that, there's no point.
Drivers don't subscribe/join, companies do. You don't take a cut of every ride, you take fees monthly/quarterly/yearly. For the driver, everything looks mostly the same, and they can still operate on a hail basis. But they can also claim dispatched rides.
Now, as the app, you don't have to give five shits about taxi regulations. About driver safety, passenger safety, driver pay, etc. That's all handled at the local level, where it should be.
You exist to provide a common payment interface and location-based routing of requests to nearby companies. And that's essentially it.
Taxi services will always be a regulated profession. There will always be certificates and exams and unions.
What "decentralized Uber" would actually look like would be a standardized protocol for taxi agencies so that with the same app you can call a taxi in NY or LA. They would have to set up a server and when you go to another city instead of calling a phone number you simply navigate to the website or put a unique code in your app and you can immediately call a taxi through them.
So it still relies on a centralised (and proprietary) messaging platform.
To achieve that without centralisation requires some variant of crypto signatures. To make them expensive to "fake", they need to cost something. One suggestion would then be to make the payment receipt the rating signature. In this scenario, drivers would publish their ratings which consist of the signatures/receipts of previous fares.
Either way, it needs to be addressed.
BitTorrent is almost as decentralized as it gets. It has no blockchain.
I don't have all the answers. But my guess is the crux in decentralizing ride sharing is reputation portability. Probably need a DID and a way to accumulate attestations, ideally directly from riders, in a fashion that the driver owns it, cannot be censored but also cannot be faked. Once that part is in place the rest is just commodity app type of deal.
black cabs in the UK(well only London) are all independent. The only thing that is common is that they have a license to operate and have passed the "knowledge"
Minicabs in the UK are different, you need to be Disclosure and Barring Service "passed" ie not a convicted sex pest. Every town used to have a number of minicab firms. You needed to know the number of a few of them. There are a number of aggregators that now act as a broker to them (even though uber exists here.)
Don't get me wrong - being able to hail a cab in central London is vastly quicker than working out which dodgy minicab app is working today. But they're hardly decentralised. They are fairly autonomous though.
Heck, if you even get banned by one for puking in the car, you can always just call a different company the next ride.
So there, I just invented it. I'm going to call it "DUber".
There are problems with Uber and Lyft, but they were both such a huge improvement over traditional cabs that it's not surprising that they quickly became popular.
That doesn't and has never required a multi $billion wedge driven into gap in the market.
The whole idea that it needed a single monolith to spark change was a nonsense.
Local relays and DHT-servers would be run on a charity-basis like tor. Also trivial.
Searching for cabs would be similar to a file search on gnutella, though I don't know the details of how that works.
The tricky bit is to make it payment-service agnostic.
This would be extremely valuable for many applications
Therefore probably hard to design/implement otherwise it would already exist.
Drivers are incentivised to stick to one phone number, and to publish these ratings (through p2p). The clients could sort them by recency, so the meaning of old signatures would eventually expire.
Just one example of how it could work.
You can trivially implement DIDs on-chain for example https://github.com/uport-project/ethr-didand have various levels of centralization and authentication, and then you can also use things like soulbound tokens (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=4105763) or on-chain activity to further correlate someones identity in a more decentralized way.
For scale, you can use a layer 2 chain to batch transactions off-chain. And then you can go further and implement zero knowledge proofs to keep identities private but attestations public.
99% of rides are local users, and of the remaining 1%, 99% of those are from a hotel, airport or local's place. In other words the concierge can call you a cab, the airport can vet the taxi stand or a trusted local can book you a ride.
IOW, the solution that might win is something like NYC's drivers cooperative. If it's the best for local users, that's enough to win and non-locals have an inferior experience.