There was a minimal amount of work done on Bitdrop, I found the project
after it had been dead for about six months and got involved trying to put
together a team which was going well until nef disappeared.

Yes, onion routing was always part of the vision.

I don't think there's any problem with you posting Hiro's podast, he hasn't
been around for quite some time and was a very open source guy.

Yes, I have seen Roadie - Roadie strikes me as egold, they have founders
they have servers they do matchmaking it's pretty straightforward as a
comparison. The only reason you get something like Bitdrop is because its
the best option in a sea of bad options, otherwise it's not worth
reinventing and boostrapping such a network.

So my timeline for something like Bitdrop not only existing but making
sense is about 10 years from now after we've seen the rise and subsequent
fall of things like Roadie, Uber, etc. Really it's all the same thing,
just that bitdrop is for long distance stuff (Whether a person or a human,
you'll probably be going more than just one leg of a journey) and a fully
distributed uber would usually have the same guy pick you up and drop you
off at your destination.

If it's in the same system, that's not actually a given - All
people/parcels wind up looking the same because even if its only a dropoff
to the next leg of a route to the person doing the dropping off it looks
exactly the same. They gave it to someone else, whether its the
destination or not.

One thing we spent a lot of time thinking about was verifiability which is
a damn hard problem, but to which there are definite solutions. My
favorite part is the local redistribution scenarios which if you've ever
worked in distribution or redistribution makes ages more sense than the way
we do things now shipping from distant centralized locations.

On a related note, anybody want to do an episode of LTB about this with
me? I've been looking for an excuse for quite some time and if there is
interest we could at least do a nice think-out that would get gears turning
in listener heads. If there was desire to actually push on the project
this would be a good way to kickstart that too. Hit me in a seperate email
if you're interested (adam@???)


Here's something else from the archives.
---

(11:18:00 AM) hercules/: Hey Voodoo
(11:18:31 AM) voodoo: hey!
(11:20:53 AM) hercules/: Was thinking I might have answered the question
wrong there for a sec, Nef just ran with it, didn't actually come up with it
(11:21:03 AM) voodoo: oh, really?
(11:21:17 AM) hercules/: You havn't read the original thread?
(11:21:33 AM) voodoo: where, on the bitcoin forums?
(11:21:33 AM) hercules/: There is a public record of the creation of the
Bitdrop concept, its pretty neat
(11:21:35 AM) hercules/: yeah
(11:21:50 AM) hercules/: it was in a thread on a robotic courier service
someone thought was a good idea
(11:22:02 AM) voodoo: I have, but it's been a while
(11:22:12 AM) hercules/: anyhow, we were both thinking nef hehe
(11:22:16 AM) voodoo: I remembered nefario as bing OP
(11:22:18 AM) hercules/: So you had questions
(11:23:38 AM) voodoo: yeah...I'm trying to separate *basic function* from
*security* from *biz model* while keeping all three in mind
(11:24:29 AM) voodoo: so, I'm just putting down desired behaviors for each
object referenced on that doc you sent me
(11:24:36 AM) hercules/: ok
(11:25:28 AM) voodoo: so, it's a complicated problem and I've attacked
first as a 2d problem - getting a package from one point to another
(11:26:02 AM) voodoo: not too tough, but really it's a 3d problem with
really interesting temporal hurdles
(11:26:11 AM) hercules/: and bootstrapping issues
(11:26:23 AM) voodoo: oh yeah
(11:26:27 AM) hercules/: like crazy
(11:26:32 AM) hercules/: that's what keeps me up
(11:27:15 AM) voodoo: so, lets start with easy stuff - I'm going to try to
paste this
(11:27:20 AM) hercules/: ok
(11:27:26 AM) voodoo: Node:
  Can have holder role
  With holder role:
    Has a location
  Can have runner role
  With runner role:
    Has a maximum travel radius
    Has a maximum volume
    Has a maximum weight
    Has a maximum single package volume
    Has a maximum single package weight
  Can have router role
  With router role:
    Has a schedule
    Has an origin
    Has an endpoint
    Has a maximum volume
    Has a maximum weight
    Has a maximum single package volume
    Has a maximum single package weight
  Has a minimum payout_expectation
  Has an identifier
  identifier:
    Has a text description
    Expires
  Can have a “job hunt” mode
  In “job hunt” mode:
    Reports its location to the server every XXX seconds.
  Can have a “static” mode
  In “static” mode
    Has a location
(11:27:40 AM) hercules/: Did that paste properly? or is it a table
(11:28:01 AM) voodoo: It looks ok from here - it's an outline
(11:28:08 AM) hercules/: ok
(11:28:35 AM) voodoo: so a node can have a role and other attributes based
on the role
(11:28:49 AM) voodoo: and then mode
(11:29:02 AM) hercules/: And you're envisioning temporary text descriptors?
(11:29:34 AM) voodoo: on what?
(11:29:46 AM) hercules/: Everyone has to have an identifier in this layout,
right?
(11:30:03 AM) hercules/: The two fields you have for that are text and
expiration
(11:30:21 AM) voodoo: yes, as written, that's true, but really only runners
and routers would have that
(11:30:27 AM) hercules/: Sorry, I'm focusing on details - What's the bigger
picture question?
(11:30:36 AM) voodoo: first note for myself :-)
(11:31:30 AM) voodoo: so the doc you sent me said a node in "job hunt" mode
would be eligible for jobs within a set radius of current_location
(11:31:59 AM) voodoo: but, really wouldn't they be eligible for jobs in a
radius based on a fixed point
(11:32:07 AM) voodoo: centered on a fixed point?
(11:32:10 AM) hercules/: it depends
(11:32:34 AM) hercules/: The doc envisions two types of terminals used for
receiving missions invites
(11:32:55 AM) hercules/: A stationary one (home/base) and a mobile one that
floats based on your phones rough location
(11:33:31 AM) hercules/: some people will spend lots of time at a central
base, but I know lots of other people who spend their time driving all over
major cities
(11:34:01 AM) hercules/: SUre they could set the radius as the whole city,
but really what they want is to know about pickups that are near where they
are right then when they're looking
(11:34:15 AM) voodoo: ok, but if my phone and I are at the edge of my
radius based on fixed point, then travel could be up to 50% greater than
I've specified
(11:34:28 AM) hercules/: you don't have to say yes
(11:34:59 AM) hercules/: I was thinking the mobile one would have a much
smaller radius than the standard fixed
(11:35:25 AM) hercules/: someone in a car might be willing to go 5 miles
out of their way when they're on the road, while someone operating from a
home base might have a range of 20 miles in any direction
(11:35:41 AM) hercules/: that of course assumes a town, not a city, as
cities will be much easier with the higher density
(11:35:58 AM) voodoo: OK
(11:36:14 AM) voodoo: that may be a moot point, though depending on some
other things
(11:36:18 AM) hercules/: I agree
(11:36:41 AM) voodoo: the doc said the runner shouldn't be able to select
the location for handoff
(11:36:45 AM) voodoo: however...
(11:36:53 AM) hercules/: well, we've gone back and forth on that
(11:37:10 AM) voodoo: bootstrapping is already a problem, and I think I may
have a neat solution to that
(11:37:41 AM) hercules/: That falls under security - The more "the system"
handles by itself, the more secure we are and the fewer interceptions we'll
have
(11:37:55 AM) hercules/: regarding runner location selection
(11:38:39 AM) voodoo: right. So how about we allow a runner to designate
multiple points where he/she feels comfortable doing handoffs, and
distance/direction they are willing to travel from there
(11:39:04 AM) voodoo: and then the system can use those multiple points in
the route calculation to a) help it create routes
(11:39:20 AM) voodoo: and b) randomize the handoff locations
(11:39:26 AM) hercules/: My concern is always with interceptions when we
talk about pre-set rendezvous that local carriers can monopolize
(11:39:46 AM) voodoo: where the receiving node is psuedo-determining
location
(11:39:48 AM) hercules/: We as humans like set patterns, but it screams
"ambush me"
(11:40:16 AM) hercules/: right, but that's just as difficult as sending a
couple packages from different places in a city to figure out the popular
rendezvous
(11:40:23 AM) hercules/: I think it can be a hybrid solution
(11:41:04 AM) hercules/: In dense areas, online mapping and social media
have done a good job of mapping out most restaurants, recreational shit,
etc.
(11:41:34 AM) hercules/: in those situations, the system should just pick
meetup locations that overlap delivery areas, no selection from users
(11:42:19 AM) hercules/: But in more sparse areas, where we'd be using GPS
coords, or just in general we have a harder time with routing then I can
see a multiple user selected option
(11:42:43 AM) hercules/: Where we have density, the system needs to just
make the right choices and not give any options
(11:43:19 AM) voodoo: just to be clear, I'm not suggesting the users
select, just that we use their localized knowledge to generate a db of
handoff locations
(11:43:43 AM) hercules/: I'm not fundamentally opposed, it just blinks red
at me
(11:44:06 AM) hercules/: AFK about 45 minutes
(11:44:21 AM) hercules/: feel free to ask further stuff, I'll address when
I get back
(11:44:27 AM) hercules/: we're going to get together as a group soon
(11:44:53 AM) hercules/: AFK
(11:48:40 AM) voodoo: ...
(11:48:41 AM) voodoo: ...
(11:48:47 AM) voodoo: <hr>
(11:50:06 AM) voodoo: so, based on all that, we run smack into the temporal
problem - a node in "job hunt" mode can only be assigned to one (maybe,
MAYBE two)-leg routes
(11:50:53 AM) voodoo: IOW, the pickup and final_desitnation points are both
within the radius of that node
(11:51:22 AM) voodoo:
.....................................................................................................................
(11:52:51 AM) voodoo: next: Package, no problem:
(11:52:53 AM) voodoo: Package:
  Has a type  # letter, box, crate
  With types box and crate
    Has a height
    Has a length
    Has a width
    Has a weight
  Has a QR code
  Has a tracking ID
(11:53:09 AM) voodoo:
................................................................................................................................
(11:53:29 AM) voodoo: Job:
  Has at least one Package
  Has a final_destination
  Has an intermediate_destination
  Newly created:
    Has a location
    Triggers Route.seek(job.location)
  In-transit:
    Has a current_node
(11:55:05 AM) voodoo: ............ again, not much controversial in the
Job, yet (the accounting and interfaces are going to be the biggest chunk
of Job)
(11:55:19 AM) voodoo:
......................................................................................................................................
(11:55:31 AM) voodoo: now, the fun part, Route
(11:56:17 AM) voodoo: this is where all the temporal problems become
mountains
(11:56:20 AM) voodoo: Route:
  Has at least one Leg
  Seeking:
    First Leg:
      Finds Nodes where job.location is within
node.radius(node.current_location) && node.mode == “job hunt”
    Low Price:
      For each node in first_leg:
        Calculates all possible routes to job.final_destination where
!first_leg.include?(Node)  # kata harry potter
        Assigns lowest-cost route to low_possible_route[node]
      Low Four:
        Selects the four lowest-cost, unique low_possible_routes
      Messages all nodes in low_four
    Fastest:
      Calculates all possible routes to job.final_destination where
!first_leg.include?(Node)  # kata harry potter
        Assigns most efficient route to efficient_possible_route[node]
      Efficient Four:
        Selects the four most-efficient, unique efficient_possible_routes
      Messages all nodes in efficient_four
  Bid:
    Returns lowest-cost low_four where all nodes accepted
    Returns lowest-cost efficient_four where all nodes accepted
    Returns most-efficient efficient_four where all nodes accepted
  Shipper Acceptance:
    For each node in accepted bid:
      Creates a leg
(11:57:45 AM) voodoo: ..................and, just for reference,
Leg...................................................................
(11:57:59 AM) voodoo: Leg:
  Has a start_point
  Has a start_point_time
  Has an end_point
  Has an end_point_time
  Has a node
(11:58:06 AM) voodoo:
.......................................................................................
(12:00:19 PM) voodoo: "efficient" is some measure based on directness of
route and working schedule of the nodes
(12:02:04 PM) voodoo: which, is the first temporal problem - any Node is
going to have to pre-determine a schedule for anything other than one-hop
routes to work
(12:03:12 PM) voodoo: IOW, the system is going to need to know which Nodes
will be available for work at the approx. time the package(s) would arrive
at any given point
(12:04:53 PM) voodoo: and, it's going to have to be able to dynamically
re-route Jobs when the inevitable no-show occurs
(12:07:43 PM) voodoo: and, it's going to have to be sufficiently flexible
to allow a Node to accept multiple legs while being sufficiently strict as
to prevent a Node from accepting conflicting legs
(12:16:09 PM) voodoo: all while making it so that the current_node knows
only where he's going and what time to be there
(12:16:24 PM) voodoo: and what the pickup node will look like

Adam B. Levine
Editor-in-Chief
Let's Talk Bitcoin! <http://www.letstalkbitcoin.com/>

On Thu, Feb 26, 2015 at 4:16 PM, Washington Sanchez <
washington.sanchez@???> wrote:

> Well I'll take the opportunity to think crazy here:
>
> Categorize the size of the package you want to deliver and match it with
> the best transportation medium and range.
>
> For example, small lightweight packages could probably be delivered by
> drone-hopping.. the number of hops would determine the delivery range. The
> flight-hop path alogrithm could access an API to a prediction market (yet
> to be built on OpenBazaar, but doesn't have to be OB) betting on the
> risk-of-interception within certain regions of a locality... if the price
> of a certain region gets too hot, the 'swarm' could alter it's flight-hop
> path to less risky route(s).
>
> On Fri, Feb 27, 2015 at 7:14 AM, Adam Gibson <ekaggata@???> wrote:
>
>> >> https://tlsnotary.org/cypherpunkd-EP043.mp3 - starts at about 35 minutes
>>
>> Btw if someone wants me to take these down, I will of course.
>>
>> Cheers,
>> Adam
>>
>>
>> On 02/26/2015 11:01 PM, Adam Gibson wrote:
>> > Hmm just realise it's discussed in ep 43 also, I'll upload that.
>> >
>> > On 02/26/2015 10:55 PM, Adam Gibson wrote:
>> >
>> >
>> >
>> >>> 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...
>> >
>> >
>> >> Sam, I'm guessing you meant the other Adam ;), but here you go:
>> >> https://tlsnotary.org/cypherpunkd-EP019.mp3
>> >
>> >> I think the onion routing idea was already there, I am not
>> >> original :)
>> >
>> >> It's near the end of the interview.
>> >
>> >
>> >
>> >> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>
>
>
> --
> -------------------------------------------
> *Dr Washington Y. Sanchez*
> Post-doctoral research officer
> Therapeutics Research Centre
> University of Queensland
> Princess Alexandra Hospital
> Woollongabba, 4102
> Queensland, Australia
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>
>