Thanks for all the info.
Did it ever reach the stage of a github repo? I couldn't see one. Not
that it's purely code of course, but still.

I'd love to see some work on it. What spare time I have is going to
joinmarket right now, and a bit of tlsnotary. Otherwise I'd love to
help, or at least find out more about it.

Agoristradio was great. A bit rough around the edges compared to what
you do now Adam, but it was a definite fav :)

Yeah there's not much to say about Roadie (and I'm pretty sure I've
seen one or two other similar setups, although not sure how far
along). Like Uber, it might be more immediately significant than a
decentralised option, because the centralization makes it so much
easier, but I can't see how it could be co-opted or leveraged, maybe I
lack the imagination to see it..

Building decentralized Uber has been sitting there waiting for someone
to do it already for ages, but it's really hard because it gets right
into the reputation/trust issue. It's notable to me that 15 years ago
I remember using "decentralised Uber" in Russia (by which I mean -
just wave your hand and get a ride from any stranger). Western
"consumers" are so soft-edged that they will reject anything that
doesn't have a perfect veneer of safety and comfort.

Hmm maybe that's Cody's point. Uber as a trojan horse sort of thing.
Uber has no "moat" to use business parlance. Ordinary people get
behind it because it's the easy option, then Uber uses the consumer as
leverage to break the monopolies, then the decentralised option steal
all its business when the consumers realise they don't have to pay
Uber a cut. Well, nice dream.

Decentralised marketplace (OpenBazaar), uncensorable and untraceable
payment (stealth addresses, coinjoin), decentralized delivery
(bitdrop?). I think the only block is the reputation/identity issue.


On 02/27/2015 05:10 PM, Adam B. Levine wrote:
> 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@??? <mailto:adam@letstalkbitcoin.com>)
>
>
> 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@???
> <mailto:washington.sanchez@gmail.com>> 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@???
> <mailto:ekaggata@gmail.com>> 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
>
>
>
>
> _______________________________________________ unSYSTEM mailing
> list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>