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@???> 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@???
The University of Texas School of Law
Class of 2014
::
Re: [unSYSTEM] Decentralized packag…
