4 ms·
People are going to hate on me, but web3 makes this absolutely trivial to build. If you try to build this as another centralized service, you just end up in th
by swalsh 4y ago
People are going to hate on me, but web3 makes this absolutely trivial to build. If you try to build this as another centralized service, you just end up in the same place but a new dominant owner.
Don't get me wrong, there IS a wrong way to build this in web3 where it's just a web2 service on-chain. But designed correctly, it can avoid the pitfall.
- PaulDavisThe1st 4y ago> web3 makes this absolutely trivial to build So good to hear. Put differently: are you insane? ps. I built the original Amazon. On top of that, I have a brother who builds web-stuff related to decentralized coordinated activities and has done for many years. I didn't check in with him, but I'm pretty sure that we both think that you're insane.
- swalsh 4y agolol, do you end every technical argument with "I'm Paul Davis, don't even try to debate me!"
- PaulDavisThe1st 4y agoI try not to. But when someone claims that building a platform for distributed, cooperative, coordinated action is "trivial", and it's in the context of "I'm building an open source Amazon", it is a little hard not to fail at this goal.
- swalsh 4y agoI used to work in large scale eCommerce too, I would never claim distributed supply chains is trivial. But this was not in reply open source Amazon, this was a reply to the idea of a distributed Uber (the parent comment to mine). That to me, feels quite in line with Web3's capabilities. The hard problems to me don't seem to be technical in nature. I think the bigger hurdles will be business related. But this is a tech conversation, so here is my thoughts. The way I see it, Uber enables 3 primary capabilities, for which it takes a major cut, and commands total control over drivers: 1. Driver Ratings 2. Payments 3. Match Making I think web3 can solve 1 and 2 on-chain using smart contracts relatively simply. and if you use a chain like Avalanche, it can be done with low fees (cents) and with fast transaction finality (seconds). The match making capability should not be on chain. For that i'd design a simple rest API using traditional technologies that consumes configuration from the chain. This service can be deployed on Akash, and paid for by taking a small cut off each transaction or devaluing a utility token... i'd build a DAO to govern the whole thing, and i'd distributes votes based on activity in the drivers pool. Are there probably problems here? yeah, this is 3 minutes of thought. But i'm sure if I cared to, I could design a functional system in a weekend.