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
>
::
Re: [unSYSTEM] Decentralized packag…
