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.