>From their FAQ:
Who are the Roadie drivers and how are they vetted?
<https://support.roadie.com/hc/en-us/articles/203361415-Who-are-the-Roadie-drivers-and-how-are-they-vetted->
From college students and soccer moms to young professionals and
retirees, Roadie drivers are a diverse bunch who just happen to have
a little extra room to deliver your stuff where it needs to go. The
one thing they all have in common? Every Roadie driver must have a
current auto insurance policy that meets or exceeds the minimum
requirements in their state, and are subject to a background
validation check and driver’s license verification. All Roadie
drivers and Senders must maintain at least a 4-Star rating to remain
in the community.
...
How does payment work?
<https://support.roadie.com/hc/en-us/articles/203361435-How-does-payment-work->
We request your credit card information to validate your identity,
which also makes it hassle-free to pay your Roadie driver. You pay
securely and easily through the Roadie mobile app after each Gig is
successfully completed. We'll send you a receipt via email, and you
can also check the history tab in your mobile app for a list of
every shipment. At the time you create a Gig, we’ll verify you have
a valid credit card as well as available funds, but we won't charge
it until the package is delivered.
I'm not sure it's easily exploitable, though that depends on what you
mean by exploiting. It's not decentralized and not pseudonymous, and
uses credit cards for payments.
Adam, do you have a link to that Agorist radio interview? I couldn't
find it. Also, do you know if BitDrop is being developed or saw any
development? I only saw an old BitcoinTalk thread, looked abandoned.
Solid ideas on this topic are floating around, sounds like it's only a
matter of time...
On 02/26/2015 02:11 PM, Cody R Wilson wrote:
> Did we bring this up yet? http://roadie.com
>
> I like it because it's very San Francisco White Liberal. Perfect for
exploiting.
>
> crw
>
> On Thu, Feb 26, 2015 at 1:07 PM, Adam Gibson <ekaggata@???
<
mailto:ekaggata@gmail.com>> wrote:
>
> Yeah I remember that interview :) I also thought bitdrop was a
> fascinating idea.
> More recently I mused with the concept of onion routing for physical
> delivery. Imagine a package with layers, each of which has the
> destination address encrypted to the courier's pubkey. If it was
> intercepted en-route nobody would know where it came from or where it
> was going to (for sufficient intermediaries). Not the most practical
> idea, but fun :)
>
> On 02/26/2015 08:28 PM, Adam B. Levine wrote:
> > Here's a workout for the bitdrop project, i'm actually working on
> > a short fiction story off it right now, absolutely fascinating idea
> > whose time seems sure to come.
>
> > Have you guys heard the interview Nefario did with Hiro from
> > Agorist Radio back in 2010 or 2011 on the topic?
>
> > ---
>
> > Bitdrop
>
> > Node Configuration: Before we can do anything with a node, we have
> > to know a little about it - If a user is based off a phone, it
> > should periodically tell the server where it is when its in "Job
> > Hunt" mode - The user should only have to set the maximum distance
> > they are willing to travel (in any direction), and the minimum
> > price they're willing to work for.
>
> > If a user is based from a static location (like a desktop
> > computer), they should be able to manually set their location -
> > This data should never be seen by anyone except the system when
> > used for route generation.
>
> > Give-Aways: Another piece of information will be hints on the
> > carriers appearance that will be sent along with rendezvous info,
> > so carriers are able to easily identify each other without having a
> > standardized appearance that could draw attention. An example
> > could be a bob dole '00 button on a green jacket, or that the
> > carrier has a mohawk. We could mandate that these be re-entered
> > every 24hrs to not give people a reason to keep the identifier
> > static.
>
> > For those using thteir mobile, when they are notified of a pickup,
> > and they accept, the must add their identifier before being allowed
> > to accept.
>
> > Selecting Locations:
>
> > Once a node has accepted a job, the system looks to the edge of
> > that nodes delivery range - It compares the delivery range of the
> > next node scheduled to take possession and picks a random
> > rendezvous point in the overlap. We would want to bias this
> > process towards public areas, but thats more about technical
> > implementation. The point is, the couriers should have NO input on
> > the hand-off location beyond defining their maximum range.
>
> > If were using google maps (and we probsbly are) we will provide
> > google maps with an area, and have it return places in the area to
> > eat, get gas, stores, and ATMs, the system will randomly select one
> > of these as the rendevous.
>
> > Two Options for route generation:
>
>
> > Daisy Chain: Basically the system looks at the originating node,
> > finds a node that connects with that, contacts that node about the
> > job, keeps doing that until it finds a node that will work then it
> > starts the process again finding the next leg in the route that
> > will accept the job. This makes sense for low density areas
> > where there are questions about the network being able to
> > functionally route. This will also have a much more accurate
> > delivery time estimate at origination. This could be improved by
> > conducting a mirror hunt on the destination side.
>
> > Shotgun Resolution:
>
> > Once we hit any sort of reasonable nodal density this approach
> > will quickly make alot of sense - Instead of going one by one
> > starting from the beginning and creating a path to the end, the
> > system would look at a broad swath of nodes looking for work in the
> > general path of the package, then offer it out to everyone in the
> > area, forming the route as it emerges.
>
> > An estimate would be retrieved that determines the variable cost
> > along the route, a markup would be applied
>
> > The Timing Problem: So in the hand-to-hand only model, the system
> > needs to be able to somehow arrange for couriers to show up at
> > roughly the same time - This is easy for short-hop transit (say,
> > within a city) but the further a package needs to go the more
> > opportunity for interuption. If the rendezvous are scheduled at
> > the initial (R)oute generation, small delays can stack up over a
> > route to really throw the schedule. To combat this, we might want
> > to instead give Nodes "Windows" of time where they should consider
> > themselves on-call for the given transit, then when the package is
> > 1 or 2 hops away, they are sent another message confirming the
> > package is almost to them, the rendezvous location, and the
> > Give-Aways of the node they are meeting.
>
> > When sending a package an overall ETA for the whole route will be
> > calculated and will be updated as the package moves from node to
> > node.
>
> > Dead Drop - Alternate Delivery Locations - Printed QR codes
>
> > Alternative People - Someone trusted, gets a printed QR code that
> > a courier takes a picture of Person recieving designates
>
>
> > Selecting locations: The interface will use Google maps to select a
> > location, basically where the user (runner or whatever) is living
> > or IS.
>
> > They pick a spot on the map and google maps returns GPS coords.
>
> > They must also enter the distance they are willing to travel from
> > that location. This is a node
>
> > A user can add multiple locations, and dates/times that they will
> > be at those locations. The user can also connect locations, this
> > becomes a route.
>
> > A route is simply two nodes that are connected.
>
> > When the edge of a node touches the edge of an adjacent node they
> > can pass a packet to each other. With enough nodes touching we can
> > get a full route from the source to the destination.
>
> > A node when they enter their information to the system can state
> > what type of package they are willing to accept.
>
> > We separate package type by risk, higher risk packages have a
> > higher cost.
>
> > A node enters the price they will charge for the delivery of a
> > standard package
>
> > Each node has a complete history, of packages delivered, lost, and
> > times involved. This hist
>
> > Definitions:
>
>
> > Node: A participant in the BitDrop Network Runner: Package Carrier
> > connecting two nodes Router: Package Carrier connecting two hubs
> > Holder: Distributed, Decentralized Warehousing
>
> > "Crazy Taxi" Model Rather than have users set time/location/radius
> > they are willing to accept deliveries in, their phone or mobile
> > device would act as a moving beacon that carries their acceptable
> > delivery radius with them. As they travel, and as jobs come up
> > within their radius (Say, 5 miles) they are offered those jobs via
> > push (They would set the device to "Accepting Jobs" or similar)
> > that would pop up on their device offering the location, pay, and
> > destination. Probably not desired time, but maybe Urgency would be
> > a factor.
>
> > This lends itself to a more on-the-fly approach vs. the scheduled
> > approach, and would be a way to fast-transit
>
>
>
>
> > ## Web Interface##
>
> > Dashboard The dashboard is a ribbon that is present at the top of
> > the webpage, it ha prominent links to: Locations section has a
> > google map to add a location and lists locations users is at
> > Incoming packages- lists time and places that a runner needs to be
> > to get a package Outgoing packages- list the time and place a
> > runner needs to be to deliver a package My Stats / Personal
> > information / Account (bitcoin) Send a package A page to enter
> > information for sending a package.
>
>
> > ## Droid ## The droid client updates the server on the users
> > general location.The client will notify the user if there is a
> > package that needs to be picked up near their location, how far to
> > travel,and how much they'll get, also when they need to be at that
> > location.
>
> > If the user accepts it then the client will inform the user where
> > to go to collect the package.
>
> > #handover# when the two runners meet to handover the package, the
> > pickup runner scans the qrcode on the package, this will get the
> > package code from the qrcode, sign it with the runners private key
> > and send the signature to the server. The server will verify the
> > code is correct for the runner and package, verify teh signature,
> > if all verifies ok then the server will notify the dropoff runner
> > to handover the package. The system then records the package has
> > been handed off, and begins again.
>
> > Wrong. Yes the package has a qrcode as a package identifier. Each
> > handover requires a new qrcode. Each time a runner hands off a
> > package to another runner the delivering runnermust scan the
> > accepting runners qrcode (this code is unique for every package
> > handoff).
>
>
> > The accepting runner then scans the package code to ensure that it
> > is the correct package. Or we could generate a unique code for
> > delivering runner to give to the acceptinng runner. So its a mutual
> > signoff between two nodes each time a package is transported.
>
> > The qrcode will be of a sha256 of the handoff code. This will
> > allow runners to predownload the sha256 code in case they are not
> > connected to the next. It means that the delivering node can verify
> > the real code with the sha once they get it (getting the real code
> > only on handoff). Then when the node next connects to the internet
> > it will inform the system of the package handoff using the code.
>
>
> > ##Quality Assurance## If we're going to incentivize success, we
> > need to not incentivize failure. On a cultural level, our
> > practices and ethos should instill accountability of the package,
> > and a trust-but-verify mentality. The system should require at
> > every hand-off that any damage be noted, and that if a package is
> > damaged while in your possession your pay will go down for that
> > action. At the same time, we should not ever explicitly take money
> > earned on other jobs from the errant node except in cases of
> > obvious malice. This also means people will not go out of their
> > way to try and "fix", hide, or do something otherwise stupid
> > because the worst that can happen to them is not get paid for that
> > delivery, and have a hit to their reputation, which is not so bad.
> > If on the other hand we have goon squads or something that break
> > your legs if you botch a package, then we invite all sorts of
> > unstable hijinx. Thats an extreme scenario, but major financial
> > consequences would have the same effect.
>
> > Insurance, exclusing the warhouse/storage nodes, each node would
> > not be able to get insurance, and generally they dont need it. We
> > can allow nodes to have some amount of bitcoin held as a bond(we
> > can even set the system to dinamicly set this up, skimming a small
> > portion off each delivery the node does, in essence saving up the
> > bond or insurance). Node with higher bonds will be able to handle
> > higher value packages and will significantly improve their trust
> > rating. If they lose or damage a package this will be taken from
> > their bond.
>
> > Users can of course withdraw their bond at anytime that they dont
> > have a package (or have accepted to collect a package) based on the
> > value of that bond. But once they withdraw their trust rating will
> > be updated right away.
>
> > ##Deux Ex Machina## For BitDrop to reach its potential, we need to
> > design systems that do not require or allow human control or
> > decision making beyond system maintenance and Nodal input. This
> > will allow us to collect very detailed, relatively personal
> > information about packages that will allow them to be routed in the
> > best way possible. If there are human eyes on that data, there
> > will inevitably be leaks and even if not there will be massive
> > liability and risk because it will be a centralization of lots of
> > private data - If this thing is open source so people know that we
> > can't see it either, they'll trust the system and the system will
> > be able to make very good choices with full information.
> > Otherwise we'll inevitably have people not marking their package as
> > "shady" because they think someone might steal it since it has
> > "shady" associated with it, then the sucker courier gets caught
> > with a pound of hashish and winds up in jail for mandatory 20yrs.
> > The system has to be trusted, and we have to convince people it is
> > in their best interest to give the system truthful information,
> > which means we have to convince them it will never come back to
> > haunt them. Bitdrop needs to be double blind, so it can see
> > clearly.
>
> > ##Storage Nodes## Efficient distribution requires the ability to
> > store quantities of products in geographic areas where they will be
> > most used, which will not always be the same place they are
> > manufactured. Nodes can choose to serve this purpose should they
> > have the space available to do so, and be in an area where someone
> > would want to store something - They would recieve the handover as
> > described above, but instead of moving it to another handoff for
> > eventual end-user delivery, they take the package to the storage
> > location. This could be a spare bedroom in a house, an unused
> > closet, a spare room in the back of a restaurant, really any nook
> > and cranny so long as the Node believes it will be safe.
> > Concievably, nodes that perform to certain standards (say, 100%
> > storage item safety/security record with more than 500 packages
> > stored, at least 20% of them determined "high value") could be
> > rated as a High Security storage nodes, which could be a filter
> > setting, and naturally come at a higher premium. Using performance
> > metrics, we can assign all kinds data driven tags to individual
> > nodes, for example by looking at the average response time for a
> > package to be called, and the point at which it hands off to the
> > first carrier, we can determine how responsive the node is and for
> > high-priority type packages, we would opt to have it delivered to a
> > node that responded faster. There are obviously lots of ways we
> > can use the data.
>
> > QR codes will be standard issue as shipping labels, but we need
> > another system to use for in-node meatspace organizational
> > purposes. Perhaps a simple A1/A3/B1 system would suffice, which
> > would let us just have people write on a space in the label
> > template, then when the system calls the package it can send it
> > like an IP address to the node, then the storage site (nodes might
> > maintain multiple storage sites) So Bosco.S1.B61 would refer to the
> > Bosco's 1st storage node, package B61.
>
> > Using a standardized system as described above would provide more
> > deniability for individual nodes once packages are en-route, but
> > they will stick out like a sore thumb if the storage node is
> > discovered. Not sure how to deal with that besides letting the
> > reputation system do its job.
>
> > We could use removable labels, so that when the storage node sends
> > out a package they remove their inhouse label marking and the
> > outside world is none the wiser.
>
> > ##Sub-Distro## Another layer of depth to the warehouse system could
> > be the ability to ship product in bulk to the storage node in a
> > meta-container, which would look like any other package to the
> > entire distribution chain including while it sits in storage, only
> > revealing itself to contain other smaller packages for individual
> > distribution once the first sale has been made, and the first
> > sub-delivery is required. This should be built into the Storage
> > Node Organizational System (SNOS) Note that the owner of the item
> > pays ALL shipping costs, including the final distribution hop where
> > it is re-shipped - Each re-ship would be a seperate transaction, so
> > to fully distribute a case of 40 pairs of shoes you would have 41
> > transactions.
>
>
> > From the user perspective (Shoe store)
>
> > I'm selling my handmade shoes for bitcoin over a commerce network,
> > I ship with BitDrop, I notice that I'm getting lots of orders from
> > one particular college town where they have become a fad. I have
> > a few options, I could contact a retailer in the area who has a
> > physical location, negotiate with for him to buy the shoes
> > wholesale and then retail them to the customers, I could just ship
> > them out one pair at a time as they are ordered, each customer has
> > to wait several days because it is geographically distant via any
> > means of transportation (Bitdrop or conventional), or you can just
> > ship a case of 40 pairs, each in a shippable shoe-box inside the
> > larger case, to a storage node in the area. When an order comes in
> > nearby (or even just closer than your production location) you put
> > together a dispatch order just as you would if you were shipping
> > it yourself, give the warehouse reciept number (this would be
> > encrypted or generic I imagine, since we don't want to tell
> > specific locations of any nodes outside of rendezvous)
>
> > Guy running the storage node gets a work order on his phone to open
> > box B61, remove one sub-parcel, attach a destination shipping label
> > to it and deliver it to the designated rendezvous for pickup. You
> > can imagine this quickly becoming a business model with multiple
> > runners hanging around popular storage nodes because of the
> > frequency of work. This allows the shoe maker to pay less
> > overall for shipping because it will be substantially cheaper to
> > ship one large case and store it until short-hop delivery vs. 40
> > individual pairs of shoes for the entire trip. It means the
> > relationship stays between the shoe-maker and their customers,
> > instead of having that relationship develop with the local
> > retailer (this is both good and bad), and it means they literally
> > have local distribution at a nominal cost. Bitdrop should allow
> > multiple types of contracts for storage, which would be offered by
> > the Storage Node as their situation changes. We Once we build up a
> > bit of mass in areas, it shouldn't be too hard to rebalance the
> > closing of existing nodes, as long as it doesn't happen en-masse.
> > Need to think more on that.
>
>
> > _______________________________________________ unSYSTEM mailing
> > list: http://unsystem.net
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>
>
>
> --
> Sincerely,
>
> Cody R. Wilson
> codywilson@??? <mailto:codywilson@utexas.edu>
>
> The University of Texas School of Law
> Class of 2014
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
::
Re: [unSYSTEM] Decentralized packag…
