Not much to add to Adams ideas, except noting that almost everyone
transport themselves every day, that is human transport aka taxi is big
market. Putting p2p on mobile phones is one alternative, but it is probably
also OK to let phones report their position to stationary computers (maybe
running a suitably modified OpenBazaar) which handle the pairing of drivers
and customers.
On Thu, Feb 26, 2015 at 7:28 PM, Adam B. Levine <adam@???>
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
>
>
--
mvh,
Mats-Erik
::
Re: [unSYSTEM] Decentralized packag…
