2 ms·

I love decentralized technologies as much as you, but it has one major obvious flaw, which is speed to achieve consensus. Riders want their ride request experie

I love decentralized technologies as much as you, but it has one major obvious flaw, which is speed to achieve consensus. Riders want their ride request experience to be flawless and fast. Dispatching would be much slower in a decentralized system and so would driver acknowledgement. This latency to consensus worsens the experience so much that you quickly will revert back to a more centralized solution. Furthermore, the anonymity from such technologies would greatly undermine trust between riders and drivers. Neither would know if their counterparty is a theif, rapist or simply doesn't have a valid license, safe vehicle or sufficient insurance in case of an accident. Really, if you stop and think about it, the decentralized model has so many obvious flaws that make it unworkable except maybe in a country with a despotic totalitarian government that uses TNCs for spying on people, such that they are willing to suffer the shortcomings for the benefits of anonymity.

ilaksh 9y ago
Latency to consensus and anonymity are common characteristics of most decentralized systems, but they don't have to be. Actually those are problems already for most if not all decentralized systems, and have many viable paths for solutions worked out (just not very popular yet).
- malandrew 9y ago
  I'm open to be proven wrong here, but I also work on two large distributed systems each with thousands of servers spanning multiple datacenters that can handle concurrent reads/writes, so I'm pretty familiar with the space. In my system, mean times between servers in the same datacenter are a few milliseconds and p99s are between 7ms and 30 ms depending on the call. Beyond a handwavy "[there are] many viable paths for solutions worked out", how exactly would you architect such systems so that you can build a solution that produces a customer experience that is competitive against a mostly centralized system now that your solution needs to contend with inter-server latencies that are about two orders of magnitude higher due to the speed of light and the network hops involved?
  - ilaksh 9y ago
    First of all, creating a decentralized Uber-style app is not the same as emulating your particular system in a decentralized way. Of course we cannot have a bunch of widely distributed computers chatting as quickly as your computers in your datacenter. The essential parts are: finding nearby drivers, maps on two screens, communicating updated position between the two phones, and payment. Finding nearby drivers means that a group of devices in the same geographic area need to be able to talk to each other. I feel like this is right up the alley of distributed systems. The GPS updates really only require communication between the two devices at ordinary internet speeds and updates every few seconds. For payment I do not need to invent anything, we can use Bitcoin, Ethereum, or any of the many high-transaction solutions that are coming out built on those or other cryptocurrencies. So if you want to suppose that it is impossible to have a high transaction rate with cryptocurrency, I don't have time to get into it. But I will say that the main thing that makes people think that is that they assume zero trust and that every single computer must validate every single transaction. Those just aren't _actually_ requirements. But give it 2 years, maybe 5 years, this stuff will get sorted out. Until then there will always be naysayers saying it is impossible.

ilaksh 9y ago

Latency to consensus and anonymity are common characteristics of most decentralized systems, but they don't have to be. Actually those are problems already for most if not all decentralized systems, and have many viable paths for solutions worked out (just not very popular yet).

malandrew 9y ago
I'm open to be proven wrong here, but I also work on two large distributed systems each with thousands of servers spanning multiple datacenters that can handle concurrent reads/writes, so I'm pretty familiar with the space. In my system, mean times between servers in the same datacenter are a few milliseconds and p99s are between 7ms and 30 ms depending on the call. Beyond a handwavy "[there are] many viable paths for solutions worked out", how exactly would you architect such systems so that you can build a solution that produces a customer experience that is competitive against a mostly centralized system now that your solution needs to contend with inter-server latencies that are about two orders of magnitude higher due to the speed of light and the network hops involved?
- ilaksh 9y ago
  First of all, creating a decentralized Uber-style app is not the same as emulating your particular system in a decentralized way. Of course we cannot have a bunch of widely distributed computers chatting as quickly as your computers in your datacenter. The essential parts are: finding nearby drivers, maps on two screens, communicating updated position between the two phones, and payment. Finding nearby drivers means that a group of devices in the same geographic area need to be able to talk to each other. I feel like this is right up the alley of distributed systems. The GPS updates really only require communication between the two devices at ordinary internet speeds and updates every few seconds. For payment I do not need to invent anything, we can use Bitcoin, Ethereum, or any of the many high-transaction solutions that are coming out built on those or other cryptocurrencies. So if you want to suppose that it is impossible to have a high transaction rate with cryptocurrency, I don't have time to get into it. But I will say that the main thing that makes people think that is that they assume zero trust and that every single computer must validate every single transaction. Those just aren't _actually_ requirements. But give it 2 years, maybe 5 years, this stuff will get sorted out. Until then there will always be naysayers saying it is impossible.