The rebuttal to this (whether or not it is appropriate) is that taking away the centralized service means that there is no filter for who you get as your driver or your rider. As a rider, I would...
The rebuttal to this (whether or not it is appropriate) is that taking away the centralized service means that there is no filter for who you get as your driver or your rider.
As a rider, I would not want a driver who has had DUIs. As a driver, I don't want a rider who parties a bit too hard and can't hold their liquor on the ride home.
The response to this is, well, a spam filter system. This would be curated by someone and end up likely with a client like (using the email example that they gave in the article) gmail that handles the spam for you.
Is this model better for the consumer or the driver? Well, maybe. Hard to say. The point is that standard protocols that anyone can use do end up with their problems.
Conversely, driving around people who drank too much is much preferable to them deciding to drive themselves home instead. If we wanna nip drunk driving in the bud, we need to direct most taxes on...
Conversely, driving around people who drank too much is much preferable to them deciding to drive themselves home instead.
If we wanna nip drunk driving in the bud, we need to direct most taxes on alcohol to making designated drivers free at point of use.
A system like this would be great provided there is proper transparency. OTOH it's still an improvement over raw hitchiking, even as-is, which I also don't think should be illegal.
I don’t think people generally drive for rideshare programs to combat drunk driving. If this protocol is meant to get a foothold, there needs to be a way to get the worst parties out of the pool....
I don’t think people generally drive for rideshare programs to combat drunk driving.
If this protocol is meant to get a foothold, there needs to be a way to get the worst parties out of the pool.
If I have a problem with a driver or rider today, I can put in a complaint to the company and get them removed from the pool. That means that the first people to go into this system would be the people that are unable to participate in the current system for whatever reason. This is a huge barrier to getting people interested.
And the method to get the worst parties out of the pool needs to not also, for example, kick women that don't tolerate a driver's sexual advances out while keeping the driver.
And the method to get the worst parties out of the pool needs to not also, for example, kick women that don't tolerate a driver's sexual advances out while keeping the driver.
This is unfortunately one of the first things I thought of when I saw this thread. I wish I were surprised at a tech "solution" like this completely failing to take something so important into...
This is unfortunately one of the first things I thought of when I saw this thread. I wish I were surprised at a tech "solution" like this completely failing to take something so important into account.
I see those concerns, but they also establish: As well as including compliance auditors and identity verification in every technical outline. With that in mind, why does this deserve more...
I see those concerns, but they also establish:
Operators are responsible for the trips they facilitate and are required to conduct background checks on both riders and drivers before facilitating a match. The TRIP Protocol enforces this by ensuring that both Operator and the driver/rider they are matched with are licensed, insured, permitted to operate in their geographic target area, and have passed a background check.
As well as including compliance auditors and identity verification in every technical outline.
With that in mind, why does this deserve more suspicion than any currently-existing "drivesharing" system, including taxis?
The things you list don't address reporting and responding to sexual harassment/violence from drivers. Most of them aren't even relevant to it, and they certainly wouldn't be considered remotely...
The things you list don't address reporting and responding to sexual harassment/violence from drivers. Most of them aren't even relevant to it, and they certainly wouldn't be considered remotely adequate for dealing with this issue from any centralized taxi service.
How do I report sexual harassment/violence by a driver in this system? How do I prevent myself from getting matched with said driver in the future? How do I get them removed from the pool of drivers so others don't get hurt in the same way? With a centralized taxi service, they can be subject to legal liability if there's a pattern of ignoring reports of sexual violence. Who's held responsible for this with TRIP?
Theoretically someone could fork the protocol and have payments facilitated through a company like Stripe or Visa instead, though you’re then adding platform risk at the protocol level.
Theoretically someone could fork the protocol and have payments facilitated through a company like Stripe or Visa instead, though you’re then adding platform risk at the protocol level.
It seems a little unpleasant to have my rideshare payment history available on the blockchain, even if it is just recording the amounts that I am paying. And as others in this thread have...
It seems a little unpleasant to have my rideshare payment history available on the blockchain, even if it is just recording the amounts that I am paying. And as others in this thread have mentioned, it doesn't seem like it has any provision from removing bad drivers from the system.
This really just sounds like another case of someone who is overly invested in the blockchain concept trying to wedge the blockchain into another place where an RDBMS is the actual best solution.
The protocol proposal does mention privacy: Not mentioned is that ZK is already built into the SPL+ standard today. For driver provisioning, it sounds like that’s the role of the Compliance...
The protocol proposal does mention privacy:
It is possible and reasonable to reduce information leakage from blockchain transactions in the future by introducing privacy-enhancing zk-SNARK technologies, and we do believe that this will be an important addition to future protocol versions.
Not mentioned is that ZK is already built into the SPL+ standard today.
For driver provisioning, it sounds like that’s the role of the Compliance Auditor:
A Compliance Auditor is a firm or individual authorized by the governance of the TRIP Marketplace to verify that Operators and Verifiers are legally permitted and operationally capable of fulfilling their assigned roles on the network.
A Verifier is a service or entity that validates claims or assertions made by users or entities within the decentralized ecosystem. Verifiers play a crucial role in establishing trust and credibility when traditional centralized authorities are not present.
It would be interesting I think for someone to produce a protocol improvement proposal (or an opposing protocol altogether) that replaced the onchain payments and governance with a RDBMS solution. I imagine it would look similar to how Uber operates internally (ironically I think one of the members behind TRIP protocol is ex-Uber.)
What I’m really not clear on in this system is how the infrastructure provider (teleport) makes their money. Are they the designated third party compliance firm? If so, would the TRIP protocol...
What I’m really not clear on in this system is how the infrastructure provider (teleport) makes their money. Are they the designated third party compliance firm? If so, would the TRIP protocol allow for a large voting bloc of drivers and riders to remove teleport, or do they in reality have some form of control, making it not truly decentralized? Or do they take the “Sybil fees”? Or something else that I can’t see?
I was curious too. So I hoped in their telegram to find out. TL;DR Teleport is just a client to the TRIP protocol, and they add their own commission on top. Here is what they said: They also said:...
I was curious too. So I hoped in their telegram to find out. TL;DR Teleport is just a client to the TRIP protocol, and they add their own commission on top. Here is what they said:
Clients like Teleport can take a commission on the client side (mobile application). But there can be multiple clients (like on web: chrome, safari, edge, brace, Firefox) so if you charge too much people will switch client
Operators can also charge what they want, but there can be multiple operators in a market so if you charge too much as an operator someone else can lower the cost by launching an operator
They also said:
We have licenses active or in process in >10 US states, and > 10 Million people in metro areas we can serve already. Plan is to get the first city live in Q1 somewhere where we have local support by drivers and riders.
I also got an invite code and tried the iOS app (just to see what it looks like, definitely can't be used in my location yet.) It seems there are two operators currently present; Four Peaks in Arizona and Emory Peak in Texas. I believe more operators and locations are being announced at a conference this week. App also had a "virtual ride" feature which, if its close to accurate, shows the price for me to get to my gym is $16 (cheapest on uber is $28.)
Uber has 33,000 employees, spends $650 million a year on debt service alone, and that's all just a fraction of their fixed cost. But 80% of their cost is variable cost, and the vast majority of that is acquiring drivers/riders, and then losing those drivers at 10% a month because their supply elasticity calculations show that bleeding 10% drivers a month by underpaying them optimizes revenue more than paying them more.
Uber charges riders more when it can, and at the same time pays drivers less when they can.
So if I understand this correctly, I could build my own client app that charges less than teleport, and the company that operates the system would not be paid at all for rides booked through my app?
So if I understand this correctly, I could build my own client app that charges less than teleport, and the company that operates the system would not be paid at all for rides booked through my app?
I think so, if I'm understanding you correctly. I could in theory build my own TRIP client and completely undercut Teleport down to the very minimal cost of the protocol by not asking for any...
I think so, if I'm understanding you correctly. I could in theory build my own TRIP client and completely undercut Teleport down to the very minimal cost of the protocol by not asking for any commission (but then, I need to think about other economics, can I operate my app client for free etc.)
Based on what the app says, drivers earn 90% of the fare, and Compliance Auditors (operators and verifiers) get the rest from the protocol directly. So I assume the commission is any added fee on top of that, and clients like Teleport will compete off the commission they add + UX and reliability of their app.
In theory, I love this, but in practice, I also want to be able to filter out any company I don't want to use for whatever reason I don't want to use it.
In theory, I love this, but in practice, I also want to be able to filter out any company I don't want to use for whatever reason I don't want to use it.
If I'm reading this properly, that would be done on the client layer, which could be just as sophisticated as tag filtering like on TwiX or wherever. This paper seems focused on the big-picture...
If I'm reading this properly, that would be done on the client layer, which could be just as sophisticated as tag filtering like on TwiX or wherever. This paper seems focused on the big-picture architecture and commercial viability rather than end-user marketability.
I think this is correct. The company behind it is teleport, which I'm guessing will act as a client on top of the protocol. Way it seems to me in analogy: TRIP = SMPT Teleport = GMail
I think this is correct. The company behind it is teleport, which I'm guessing will act as a client on top of the protocol.
Way it seems to me in analogy:
TRIP = SMPT
Teleport = GMail
The rebuttal to this (whether or not it is appropriate) is that taking away the centralized service means that there is no filter for who you get as your driver or your rider.
As a rider, I would not want a driver who has had DUIs. As a driver, I don't want a rider who parties a bit too hard and can't hold their liquor on the ride home.
The response to this is, well, a spam filter system. This would be curated by someone and end up likely with a client like (using the email example that they gave in the article) gmail that handles the spam for you.
Is this model better for the consumer or the driver? Well, maybe. Hard to say. The point is that standard protocols that anyone can use do end up with their problems.
Conversely, driving around people who drank too much is much preferable to them deciding to drive themselves home instead.
If we wanna nip drunk driving in the bud, we need to direct most taxes on alcohol to making designated drivers free at point of use.
A system like this would be great provided there is proper transparency. OTOH it's still an improvement over raw hitchiking, even as-is, which I also don't think should be illegal.
I don’t think people generally drive for rideshare programs to combat drunk driving.
If this protocol is meant to get a foothold, there needs to be a way to get the worst parties out of the pool.
If I have a problem with a driver or rider today, I can put in a complaint to the company and get them removed from the pool. That means that the first people to go into this system would be the people that are unable to participate in the current system for whatever reason. This is a huge barrier to getting people interested.
And the method to get the worst parties out of the pool needs to not also, for example, kick women that don't tolerate a driver's sexual advances out while keeping the driver.
This is unfortunately one of the first things I thought of when I saw this thread. I wish I were surprised at a tech "solution" like this completely failing to take something so important into account.
I see those concerns, but they also establish:
As well as including compliance auditors and identity verification in every technical outline.
With that in mind, why does this deserve more suspicion than any currently-existing "drivesharing" system, including taxis?
The things you list don't address reporting and responding to sexual harassment/violence from drivers. Most of them aren't even relevant to it, and they certainly wouldn't be considered remotely adequate for dealing with this issue from any centralized taxi service.
How do I report sexual harassment/violence by a driver in this system? How do I prevent myself from getting matched with said driver in the future? How do I get them removed from the pool of drivers so others don't get hurt in the same way? With a centralized taxi service, they can be subject to legal liability if there's a pattern of ignoring reports of sexual violence. Who's held responsible for this with TRIP?
Alright, thanks for answering. If operators are responsible for the trips, then there's your liability. That seems relevant.
This would've been really cool if only it wasn't a crypto/NFT thing
Theoretically someone could fork the protocol and have payments facilitated through a company like Stripe or Visa instead, though you’re then adding platform risk at the protocol level.
It seems a little unpleasant to have my rideshare payment history available on the blockchain, even if it is just recording the amounts that I am paying. And as others in this thread have mentioned, it doesn't seem like it has any provision from removing bad drivers from the system.
This really just sounds like another case of someone who is overly invested in the blockchain concept trying to wedge the blockchain into another place where an RDBMS is the actual best solution.
The protocol proposal does mention privacy:
Not mentioned is that ZK is already built into the SPL+ standard today.
For driver provisioning, it sounds like that’s the role of the Compliance Auditor:
It would be interesting I think for someone to produce a protocol improvement proposal (or an opposing protocol altogether) that replaced the onchain payments and governance with a RDBMS solution. I imagine it would look similar to how Uber operates internally (ironically I think one of the members behind TRIP protocol is ex-Uber.)
What I’m really not clear on in this system is how the infrastructure provider (teleport) makes their money. Are they the designated third party compliance firm? If so, would the TRIP protocol allow for a large voting bloc of drivers and riders to remove teleport, or do they in reality have some form of control, making it not truly decentralized? Or do they take the “Sybil fees”? Or something else that I can’t see?
I was curious too. So I hoped in their telegram to find out. TL;DR Teleport is just a client to the TRIP protocol, and they add their own commission on top. Here is what they said:
They also said:
I also got an invite code and tried the iOS app (just to see what it looks like, definitely can't be used in my location yet.) It seems there are two operators currently present; Four Peaks in Arizona and Emory Peak in Texas. I believe more operators and locations are being announced at a conference this week. App also had a "virtual ride" feature which, if its close to accurate, shows the price for me to get to my gym is $16 (cheapest on uber is $28.)
I also checked their twitter, which has this comparison to uber:
So if I understand this correctly, I could build my own client app that charges less than teleport, and the company that operates the system would not be paid at all for rides booked through my app?
I think so, if I'm understanding you correctly. I could in theory build my own TRIP client and completely undercut Teleport down to the very minimal cost of the protocol by not asking for any commission (but then, I need to think about other economics, can I operate my app client for free etc.)
Based on what the app says, drivers earn 90% of the fare, and Compliance Auditors (operators and verifiers) get the rest from the protocol directly. So I assume the commission is any added fee on top of that, and clients like Teleport will compete off the commission they add + UX and reliability of their app.
In theory, I love this, but in practice, I also want to be able to filter out any company I don't want to use for whatever reason I don't want to use it.
If I'm reading this properly, that would be done on the client layer, which could be just as sophisticated as tag filtering like on TwiX or wherever. This paper seems focused on the big-picture architecture and commercial viability rather than end-user marketability.
I think this is correct. The company behind it is teleport, which I'm guessing will act as a client on top of the protocol.
Way it seems to me in analogy:
TRIP = SMPT
Teleport = GMail