networks + planet / finance + society / tech + art

What might a Coop Uber look like? (or should we be thinking bigger)?

Given Uber's ability – in spite of owning no cars and employing no drivers – to swiftly grow and dominate any market it enters, there's understandably a lot of interest in a driver-owned Coop competitor, not least amidst growing controversies and opposition. In this article, two coop structures are explored, as well as a third, more open and decentralised protocol option.

I learnt of an interesting coop recently: the Depository Trust & Clearing Corporation, responsible for clearing and settling most US securities (i.e shares & derivatives). At the heart of global neoliberalism is this user-owned coop, holding some $40 trillion in securities and running a service the entire economy depends on. I’d already been surprised enough to learn that Slaughter & May, the leading corporate law firm repping half of the FTSE100, was a mutual partnership with no hierarchy or even boss, amongst hundreds of profit-sharing partners.

If the temples of capitalism embrace user- and worker- owned structures, then why not the digital world? There’s understandably already a lot of interest in the idea of a Coop Uber. As Mike Konczal pointed out last year, Uber is rare in that the assets that make up the company’s service are owned by the workers:

“Given that the workers already own all the capital in the form of their cars, why aren’t they collecting all the profits? Worker cooperatives are difficult to start when there’s massive capital needed up front, or when it’s necessary to coordinate a lot of different types of workers. But, as we’ve already shown, that’s not the case with Uber.”

Uber takes 20% for connecting drivers with passengers, potentially a significant chunk of the estimated $50bn/year generating global taxi industry. In January I looked at how Uber's success was in providing a better interface for both drivers and users, but of course interfaces are considerably cheap to build than fleets of cars or offices. Cory Doctorow backed an Uber Coop at this summer’s FooCamp, tweeting:

Uber's not a charity. If it can't provide more value than its drivers could provide for themselves, it deserves to be disrupted #foocamp

The issue is relevant across the digital economy where certain sectors have, as Justin Fox on Bloomberg says “a tendency toward natural monopoly; as you attract more people to your platform, it becomes more valuable”.

Services who benefit from large databases – be it the most drivers, songs or people’s stuff for sale – will inevitably end up dominated by the service with the most or best records in the database. Network effects dictates that the biggest gets bigger, and there are few ideas about what to do about it beyond accepting it as an operating condition of Web 2.

Fox concluded that “it is possible to imagine that years down the road, when these marketplaces are mature businesses, there might be advantages to running many of them as cooperatives instead of as shareholder-owned for-profit corporations”. Coops are one of those strange semi-socialist structures that fits comfortably within capitalism, yet runs closer to the Catholic economic theory of distributism. Already some taxi firms are shifting: in Denver, where a driver-owned taxi coop of 250 members was formed in 2009, another is on its way with over 1000 members.

Post-Kickstarter, it’s easy to picture a writer-owned Kindle or a filmmaker owned YouTube — being funded and supported by sufficient numbers of disgruntled writers or filmmakers to power it into life. With the rise in ‘worker-on-demand’ applications coops could be a way to offset regularcriticism about how these services reduce worker rights.

But for now it’s challenge enough to try to picture what a coop Uber might look like, which is the question I’ve spent some of my spare moments this summer considering. In this long read, after outlining two relatively conventional coop structures, I explore a third option that has more in common with the web and decentralised systems such as Bitcoin.

Option 1. The mega-coop

A logical starting point is simply to recreate Uber/Lyft/Halo/etc, with their global network of offices, drivers, marketing and technical infrastructure, as a driver-owned coop, operating either non-profit or with its profits distributed amongst drivers. It would need to be a large, well financed organisation with a legal and customer service team in every country it operated in.

This would need a financing model that dealt with the initial startup investment, the growth funding and the ongoing day-to-day costs. The startup costs could potentially be raised through crowdfunding, or with a community share offering, such as those offered on MicroGenius, so that backers could get a return on their investment. Given Uber has raised a sizeable $7bn across 12 rounds the amount of capital needed would be considerable, while balancing the potential demands of investors against the needs of a democratic member-owner organisation, would be key. Day to day costs could be covered, as with Uber, through a percentage on fares, through monthly/annual membership fees, through licensing API access to external providers, or some combination.

Although costly to setup, a single-coop competitor is appealing because it would be easier to manage, brand and offer users and drivers quality assurance. It would require a commonly agreed-upon set of regulations and pricing, which every taxi would have to follow, so as a democratic organisation would need to find ways to agree pricing and rules across national and regional differences between its members.

Internal voting and localised rules could mitigate some of this, but given the scale such a service would need to expand to have any hope of competing against Uber, the democratic aspects of the organisation may well need to come secondary to the initial growth strategy. Indeed there are no successful giant digital democratic coops working on an Uber scale of 160,000+ drivers to hold as an example. The coop would have to find the right balance between the risks of being so democratic it was slow or unresponsive, against being an unaccountable and top-down behemoth. And, of course, if a success it could still end up with monopoly power, and the ability to force users and drivers to follow a one-size-fits all set of rules.

Option 2. Federation of existing companies

Another, lower-cost approach would be a coop that produced software and services for existing taxi companies who already have offices, relationships with drivers and passengers, and often leasing agreements and insurance schemes around their fleet of cars. This would both distribute control out beyond the central coop, responsible for creating software, and work to build upon an existing networks, brands and services, rather than striving to throw them all out of business.

The coop in this instance would produce ‘white label’ software to manage drivers and payments for each of the companies, and also a single branded app which the user downloads. At this point either all the companies in each city and region would need to agree on and use the same prices, or the app would need to indicate that different cars were from different companies and had different prices. By letting each taxi company set their own prices this would create greater potential for competition and variation – car company X with the older cars is 20% cheaper than taxi firm Y which only has recent Sedans, while company Z has a 100% electric fleet of Tesla cars.

As well as offering more choice and competition, it also removes from the main coop the burden of verifying and approving new drivers’ identifies or providing customer service. It is closer to an infrastructure, software-as-service company, serving it’s members, who are all established companies. On a simple level, this already exists - a company like Mowares offers an Uber clone from $400. What a coop — owned by all the local taxi companies paying for installs — could further do, is ensure that each install could communicate with each other and produce a single app for users to download that connected them to all of their local taxi companies.

Most appealing about this model is how little cost it would take to achieve scale, provided it was supported by sufficient taxi companies, while also dealing with any potential legal problem, by passing the problem over to taxi companies who have long operated in the local/national environment.

Nevertheless this approach maintains the middle-man, the taxi company – an extra cost which Uber has removed. Part of Uber’s ability to charge low fares is replacing the expense of taxi offices, switchboards and phone receptions with software, reducing the cost of journeys. So this coop model may always end up more expensive than Uber or Lift as it needs to pay both driver, the coop producing the software/service and the taxi companies representing the driver. While some companies, such as executive car services, with account management, may offer sufficient value to justify the added cost, it’s hard to imagine the cost-conscious end of the market acting in the same way. It may require, as Seth Ackerman proposed, cities and countries making a legal requirement for taxi-apps to be worker-owned to succeed.

Of course this is also no help for the driver who, for whatever reason, doesn’t want to join the local taxi-company, or can’t, which may be an issue in areas where there is only one taxi service. But a service which lets drivers register directly has a much greater administrative burden and legal liability around verifying drivers and their licensed vehicles. To do the verification job well, the model ends up more centralised and much closer to the first option above.

Interlude: trustiness as a sliding variable

All that I’ve read and my thinking for most of the summer seems to move between these two models - either a large centralised coop that verifies individuals who join up but that risks being undemocratic and less nimble and innovative; or a more decentralised, federated system that only works with companies who in turn take responsibility for driver management and verification.

But then I was remembering hitchhiking in France as an eleven-year-old with a girl who had told me loudly I had a bum-chin (a chin so dented as to have its own cleavage). We decided to sneak out of the tedius campsite and hitchhike to the nearby town. It seemed a suitable adventure and we were aware enough of the risks not to tell anyone lest we were stopped, although not aware enough of them not to do it. We squeezed into a smoke-filled Citroen with three men quite oblivious to any dangers. They dropped us at the supermarket, where I bought a bottle of wine to take home, and we hitched back.

Hitchhiking was – and in many places still is – normal, despite there being no identity checks and the occasional, mostly fictional horror story. Because of this it’s something both the driver and passenger do at their own risk, with their eyes wide open — somewhat like giving your credit card details to a website in the 90s. By comparison, a system that records you as a person getting into a specific car, licensed to another specific person at a particular time and location, is many orders of magnitude safer than hitch-hiking. Lift sharing and car-pooling websites have far softer requirements than paid-services – liftshare.com seeks only a verified email address to offer and cost-share a trip you are making – but there are no publicised problems with car-sharing scams.

In other words, perhaps trust is something relative to time, circumstance and conditions. If I’m stuck at night in a remote rural location having missed the last bus - I’d hop in a car with almost anyone if it’s the only one nearby. If it turns out that someone in my office block is making almost the same trip to work each day, even tho I don’t know them I’d be happy to share a ride and split the petrol. If I need to get from a train station to a meeting at the last minute, then I’d want a driver who knows how to handle the city in rush hour. If I’ve got to do an early morning long distant trip to an airport as all the public transport is down, I might just want to go with the cheapest price I can find.

So, maybe trust is a design challenge as much as a service issue: rather than create a service with a 'guaranteed leve' of security, you could create a service with varying levels that the user is made well aware of. Then, instead of than having apps and coops for different forms of car sharing, you could design and build an architecture – a set of protocols and systems – for car journeys, and build the coop app on top.

Option 3. A distributed architecture for journey data

It's the jumping the shark idea: and it may be easiest to explain the idea by looking at the web, which illustrates well how much a decentralised, open system with lots of competition at every level can achieve.

URLs are unique, point to websites and are either encrypted, with a certified level of encryption and a https:// prefix, or are unencrypted (http://). These websites can run a huge choice of software and sit on many types of servers; competing search engines can all index these websites and serve up the results through browsers which are viewed by the end user across phones, PCs, tablets, TVs and so on. There’s a total, genuine free-market in devices, browsers, search engines, websites, servers, the software that runs on servers - and this potential anarchy of decentralised maximum-competition is all held together by a commonly agreed naming system pointing to every site (the URLs), and some open source code - HTML, javascript, CSS and HTTP - that everything across the system can understand.

A protocol for journeys, rather than pages, could achieve something similar.

Any driver with a car that wants to offer lifts could be identified with a unique URL: mydonutrickshaw.car or 123.456.789.101112. Maybe they paid for a security certificate to verify their identity and driving/taxi license, so they are a ‘secure’ https-like URL, or maybe they didn’t.

Someone wanting a lift fires up an app with their phone. It’s already got their preferences stored - they’ll take any lift from Facebook friends, people in their address book, or who work in their company - as well as drivers from Addison Lee, Uber, Lyft, the new Tesla.Coop or any trusted ('https') drivers with a minimum 6 months experience. On telling the app the journey they want to make, they see that there’s an expensive executive car available within five minutes, and a dozen cheaper options in up to 30 minutes, one of whom they’ve travelled with before and liked. If they wait another two hours, there’s a neighbour who will be in the area and will be driving back directly. All this information is pulled from across the system, and all is designed to prevent any single player dominating or monopolising the market through a technical or data monopoly advantage.

How could this work?

This approach has four elements - Coop, Open Source, Register & Semantic data (which, as I drafted this in Dublin airport, I abbreviated as CORS):

A Coop, funded by its members, in charge of building and maintaining…

Open Source Software, available to anyone who wishes to use or modify it, provided they register on a…

Register, a method to provide a trustable, yet decentralised index of all users, drivers, and groupings (i.e. Taxi firms). It could be run on the blockchain, and its records are stored at uniqiue URLS using…

Semantic data to store information for each URL, unique to each user, driver or group – with access control revealing differing information depending on who is asking, and which any other parts of the system—if allowed—is able to read and interpret meaningfully.

This approach is loosely parallel to the web’s architecture of:

Worldwide Web Consortium, a non-profit organisation funded by its members to approve…

HTML/CSS/etc specs, powering websites whose address is stored by…

ICANN, the global domain name registry, which points to…

Http web servers, which resolve domain names into working websites, and can be hosted anywhere.

Concepts explained

Semantic data

Semantic Data is a data model pushed forward by Tim Berners Lee shortly before the Web 2.0 explosion. Most sites work by keeping data in a database which pump out the data they’ve been asked for on a page as it is loaded. A semantic page is designed so that all the data can be read on the page as easily as if it was a database (while still looking the same to the end user). This means you don’t need a database that everyone can access to get meaningful, structured information, as long as you can visit the web page, that’s enough.

So, for example, as well as saying, "Buster Keaton was born in Kansas in 1895", the page also contains markup (ie hidden added bits) –

– so a machine reading it can figure out the age and birthplace of Buster Keaton, without having to log into a central database. Had we adopted Berners-Lee's proposal in our websites from the early 00s we would have a more open, less monopolised web (although only recently has the technology to handle fast concurrent web connections got to a level to make it more viable).

Register / Blockchain

Registers are 'authorative lists you can trust'. If you have a network of semantic pages, be it pages about cars, or songs, or people, you need a method to find them. In this instance, a register is a database or list of all semantic pages. It may contain a name or place and it’s associated url. Anyone in the network who wants to find information can use the register to find the relevent page. This means that database changes happen at a page level (someone changes their address or name), while the register simply adds or deletes entries.

A blockchain is a way of running a register without a central registry. This prevents too much power in the network being in any single point of failure - it offers redundancy that protects against hacking, server downtime, or abuse of hosting power. It works by sharing the work of adding and ammending records in the registry amongst many computers, who each process a small part of the overall workload, often - as with Bitcoin - in return for a payment (a part of a bitcoin). The blockchain is open — it may contain encrypted parts, or point to semantic pages that can only be decrypted with certain permissions – but stores records of additions and changes publicy.

As with the web, certificate authorities could add a further level of trust by granting to drivers a machine-verifiable certificate guaranteeing they are who they say they are.

This model has a few aspects:

Creation by the coop of the open source software used by both taxis and users is funded by a set of a founder members who will benefit from the service, be it cab companies, taxi-driver unions or individual drivers. Locking-in funding ensures the software is supported and delivered to the needed standard. This could be returnable investment as with a community share offering, or it could be donations or a share of earnings.

While this coop controls the release of the software and defines the schema or structure of the data people must include - it does not own the network of drivers — anyone publishing a semantic page about their car in the correct format and joining the register/blockchain is in. So without being a member of the coop, say, a taxi company in Delhi could host semantic data (i.e. a page of machine readable information) on each of the cars in its fleet, and as soon as the cars are registered, anyone using the taxi software in Delhi would see these cars in their service.

Conversely, anyone could build interfaces to read and interact with the data, or integrate it with their service, be it a conference venue wanting to offer taxi-booking from their event aps, or a procurement system trying to pre-book cars at the lowest price. Uber could offer non-Uber cars through it’s app when its own weren’t available, and likewise offer Uber cars through other apps; drivers meanwhile could chose to work through taxi coops and peer-groupings, under a bigger branded umbrella or on their own, keeping the maximum share of the fare.

Maintenance of the blockchain/register would have a small cost associated with it, which could be paid for either by processing new information added to the blockchain (i.e. in-kind processing across all apps) or a very small payment per transaction. Similarly the core coop would depend on continued funding, which may be through membership fees or a flat, low, levy.

The problems and challenges

Even with this structure there are significant challenges for a distributed system to overcome.

There's issue of payment: a traditional cash-fare taxi ride stores no details about the passenger or the driver (unless the passenger makes a note of the car registration or taxi license number). Part of ride-apps’ appeal are their cashlessness; for this to work in a decentralised form the user would need to store card details on their own device, uploading the information or making the payment to their driver upon arrival in a dependable, secure way, with some fallback in case their phone lost battery or signal.

Would the technology require the driver and user to have the latest phones? How would a cutting edge service address the difference in smart-phone capabilities across the world?

Privacy and security is fundamental: the driver and passenger would want to keep track of their journeys and how much they had earned or spent on each, but there could be risks if each user’s journey data was stored with the driver, revealing private address and movements to anyone who accessed the driver’s account.

There's the challenge of building a map of geolocated taxis, sending new coordinates every few seconds. Finding a stable decentralised method to map a stream of ever-changing data such as locations may be more trouble than the cost of paying for a central service to provide that.

How do you design to clearly indicate different levels of trust/knowledge around different drivers without quantifying drivers down to just numbers? Get this wrong and the end-user is at risk from not knowing if they can trust drivers, and the driver risks being penalised unfairly.

It would be naive to describe these issues as trivial; they aren’t and this doesn’t even begin to cover things like getting sufficient drivers and users to make the system worthwhile — Uber already has a significant first-mover advantage and has spent billions of dollars getting to where it is. Many of the challenges to overcome combine engineering with social/business challenges — which is largely untested waters for many open source communities, although far more normal for cooperatives. An advantage of this is that the coop and open source world each have different yet vital skills and experience to contribute to making something like this happen.

A first step might be to prepare a draft protocol and software proposal and through a series of code-sprints, tele-seminars and conference meetups iron out potential problems and bottlenecks, before forming a multi-stakeholder coop to crowd-fund/crowd-equity a test stack of software. Ideally this would centre around one or two cities, perhaps those which have banned Uber, and to test it at scale with local investment, before trying to roll it out any wider and begin to deal with multi-lingual, multi-currency, multi-legislative environments.

These challenges, tho sizeable, don’t seem insurmountable – this doesn’t seem as complex as landing a robot on an asteroid accelerating through space, while the $50bn+ annual turnover of the global taxi market makes any competitor to a model like Uber, taking up to 20% on every journey, as both credible and fundable.

Indeed the potential rewards for solving this would bring much needed competition to sharing and worker-on-demand space. Imagine a decade or two from now having just one taxi company for the world, or one freelance employment agency, or one letting agency, each with total control over their market, their pricing and worker terms. It would be as if to take the worst parts of totalitarian communism, privatise them and hand over to a single company.

Instead we need an architecture that provides all the benefits of app-based ride-ordering yet maximises competition and – like the web – is open to unlimited participants and new ideas. A decentralised system encourages innovation because the cost of exploring new ideas is far lower and less risky than if it had to take place within a large, cautious corporation or coop. So, if someone finds a way to offer drivers passing takeaway restaurants on the way home extra cash for picking up and dropping of pizza, or to let a business sync their spare vehicle capacity with a same-day delivery service, the architecture would easily accommodate startups around that. If a large UPS-sized shipping company wanted to use the data to forecast when and where roads would be busiest, it could. In other words, the question is less about offering a coop version of Uber as much as using a coop to offer an open, free protocol for car journeys that could run Uber and any number of coops and alternatives sitting on top. It’s a more complex approach, but one that runs closest to the collaborative decentralised network economy and culture we’ve collectively been building this last few decades.

Building a co-op Uber alternative that returned Uber's share of the $$ to riders/drivers is "as hard as making Linux..." #foocamp

Comments

I've read many articles similar to this one touting the alternative of turning Uber into a coop. Bashing Uber in organized labor circles seems to in in vogue. The primary basis of this reasoning is that since the workers own the assets of the company (the cars), then they should cooperatively own the company. This view is flawed since is assumes that the only assets of the company are 'the cars.' Uber takes roughly 20% and in some circles this seems to be too much.

If Uber (or other Uberish companies) were to become coops with cooperative ownership based you having a car, who's going to develop the software platform for your coop to run on (or maintain it it when it needs to adapt). Who's going to fight the legal battles that inevitably will come up (and yes there will be legal battles - regardless of your coop status). And who's going to market your coop and pay for that marketing. These are only a few of the expenses that are paid for in the 20%.

It appears to me there's a lot better targets for cooperative economic opportunity than Uber and others like it. Uber may not be perfect, but its model is a lot better than the traditional corporations that rely on medieval hierarchies and fixed work time servitude.

Hi Clay, sorry for the delay – this comment was buried in spam.I'm not sure if you read the article before commenting, but it answered your questions about developing the software and dealing with the legal issues, which I spell out would be big. Indeed the purpose of the article is to try to answer the questions about how it would work. I will leave it to others to decide if that should happen or not, but speaking with Uber drivers who work 16 hours straight at the weekend, can't charge while the car is waiting for a late customer, no longer get tips and have to give 20% away – all to earn far less than they used to as a minicab driver – it seems like there is huge room for improvement. There are surely enough problems in the world without shifting to systems that worsen worker conditions, drive down wages and so increase inequality.

I do trust all the ideas you have introduced in your post. They're really convincing and will definitely work. Nonetheless, the posts are too short for newbies. May you please prolong them a bit from next time? Thanks for the post.

Great Read! Thanks for the contributions of intellectual stimulate! Your wish is my command. I started Wee Go
( www.WeeGo.rocks ), a new Start Up Ride Share Coop, one of the first of it's kind. Wee Go is OWNED by the Drivers. Wee Go Drivers keep 100% of their Fares and Earnings. Wee Go was developed by a Team of Software and Transportation engineers and Beta Tested over the past 18 months and is now being Launched via Wee Go! It is flawless and our Beta Test drivers love it!

Your replacement system could be implemented with free software. That would get rid of the first wrong of Uber. But it is premised on identifying and tracking passengers -- on that score, it is just as unacceptable as Uber.

When I say "unacceptable", I am not exaggerating. I will never ride in an Uber car. I use ordinary taxis because they do not know who I am.

An ethical replacement for Uber has to respect users' anonymity and their freedom. It should be possible to call for a cab with an ordinary phone call using any phone. And it should be possible to pay cash, without being identified by the system.

I can think of various other ideas for assuring security for passengers. In any case, tracking people is subjecting them to insecurity.

I agree with you privacy is a key problem with what I suggest. It worried me when writing it but not enough for me to try and fix or not publish. I’ve two thoughts around this:

1 - It makes sense that cash transactions can be anonymous, but once digital payment is included the user/customer probably wants to be able to see a history of their trips and charges, in case they are mischarged/double-charged/frauded/etc. Presumably they could store that info on their own phone - but at the point they want to dispute a charge (‘I never took a cab from NYC to LA, I’ve been hacked’) it seems like some kind of double ledger would be needed? ie a hashed record on the driver’s dbse that matches the user’s? Presumably a keyed pair could still have some privacy protection by not making it identifiable to the user, but to the transaction (ie driver and passenger’s personal records both point to the same ’trip X’ on a register, but trip X does not point to the passenger).

2 - Traditional physical taxi stands have a sort of screening/vetting process - a passenger walks in, requests a cab and the dispatcher can make a human assessment about the person (are they too drunk, have they been banned previously for running away without paying, etc). Bookings made over the phone have a traceable phone-number, which can be barred. Offering the driver some way to know who they are transporting offers some security in a digital transaction that otherwise is so anonymous it could be exploited: pick me up from warehouse A, take me to warehouse B and trust that I won’t steal your car - might exclude certain people (ie drivers who are not large or fit) from wanting to use the service. Do you think there could be a compromise ‘identity verifying service’ – who can verify that I’m a real person as a passanger, but who doesn’t pass this information onto the driver, taxi-company or any part of the process, they simply say I’m real. If the taxi driver ends up dead with their car vanished, then the police can request the full identity from the service. But until then it was secret from all parties?

Of course there’s a difference between tracking an identity in order to take a credit card payment, and tracking where that identity travels to – the second part isn’t required, unless, as in point 1, the passenger wants to tracker previous journeys and payments.

In either case would you mind me posting your thoughts on the original blog post as it clearly raises an important point?

1 - It makes sense that cash transactions can be anonymous, but once digital payment is included the user/customer probably wants to be able to see a history of their trips and charges, in case they are mischarged/double-charged/frauded/etc.

I think you are assuming the digital payments work like today's credit cards: you say, "My number is XYZ" and they charge you.

With bitcoin, or with GNU Taler (see taler.net), you will keep your own ledger and there is no chance of fradulent charges.

However, it is true that cash is superior. That's why it is vital for the system to allow riders to pay cash.

that info on their own phone - but at the point they want to dispute a charge (‘I never took a cab from NYC to LA, I’ve been hacked’) it seems like some kind of double ledger would be needed?

This scenario is only possible for credit cards and services like PayPal. It is not an issue for bitcoin or Taler. If you doubt me,try filling in the missing details and let's see if you can come up with a real scenario. How did this fraudulent transaction occur? How could a payment leave my wallet without my approving it at the time?

2 - Traditional physical taxi stands have a sort of screening/vetting process - a passenger walks in, requests a cab and the dispatcher can

I am surprised that you expect there is a dispatcher.

In my experience, dispatchers are present only at places such as airports and major train stations, where a large flux of people takes taxis, or in poor countries.

There are two taxi stands near my office at MIT, and I usually find a taxi waiting there, but there is never any dispatcher present at the scene.

Bookings made over the phone have a traceable phone-number, which can be barred.

Often it is a pay phone.

Maybe the reason our expectations differ so much is that things are different in yoru country. What country do you live in?

This is what I have seen in the US. Even if things are different in your country, this way DOES WORK. There is no need to identify the passengers.

pick me up from warehouse A, take me to warehouse B and trust that I won’t steal your car

This is not a real problem in the US. People hail a cab on the street and the cab takes them somewhere. Then they pay cash (or, if they are thoughtless about privacy, with a credit card).

20 years ago, in some cities, robberies against cab drivers were common enough that drivers were really concerned. But they didn't make passegers identify themselves -- they used other solutions.

With bitcoin, or with GNU Taler (see taler.net), you will keepyour own ledger and there is no chance of fradulent charges.

This is true, although not at Uber scale in the near-term. But as you say, cash - and presumably card payments could always keep personal information with the payment provider rather than driver, who records only the journey and how much they received.

Maybe the reason our expectations differ so much is that things aredifferent in yoru country. What country do you live in?

In Britain - where most cities have a licensed taxi company who gets to operate at the ranks - and outside stations, as well as do street-pickups, and then there’s mini-cabs. In London, the licensed ‘black cabs’ have to complete ‘the Knowledge’, memorising much of the AZ, while minicab drivers can just use satnav. These usually have an office, identified with a flashing light outside, handling phone orders, counter and dispatching - and aren’t allowed to pick people up in the street. They’re probably the trade that’s lost most to Uber.

Anyway I really appreciate your points - and hadn’t seen that essay of yours before, thanks. Given the security issues that have arisen with uber’s introduction it felt that the success of a more decentralised and open system would be dependent on trust and safety. I almost take surrendering my anonymity for granted with so many services now, I instinctively assumed removing it would worsen safety/trust. That the system works without human dispatchers in the US suggests that doesn’t need to be the case.

Incidentally, I don’t suppose you had any thoughts which, if any, of the three structures may be better placed for an open Uber, assuming each resolved this issue?

This is true, although not at Uber scale in the near-term. But asyou say, cash - and presumably card payments could always keeppersonal information with the payment provider rather than driver,who records only the journey and how much they received.

Card payments trash privacy totally. The credit card company knows a lot about what people buy with each payment. Furthermore, using the card identifies the cardholder to the merchant.

The system MUST accept cash!

I have used black cabs -- anonymously. The fact that drivers are well regulated is a plus, as I see it. People trust black cabs, which shows that identifying and tracking passengers is NOT needed for their safety.

I have never used a minicab. Can you use a minicab without giving your real name, and pay cash?

Incidentally, I don’t suppose you had any thoughts which, if any, of the three structures may be better placed for an open Uber, assuming each resolved this issue?

Option 2, if you want to have uniform prices, could violate antitrust law (though IANAL). I suggest that the way to achieve such uniformity is through the taxi licensing mechanism. That is generally accepted and (I presume) has no legal problems.

In principle I think option 3 (distributed) is best.

But here I see an example of how existing injustices get accepted uncritically and new systems force people into them.

Someone wanting a lift fires up an app with their phone.

Please don't presume the passenger invites tracking by carrying such a device.