Donate to Dyne.org

(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

このメッセージは次のスレッドの一部です:
	日付によるスレッドの仕分け
	Washington Sanchez 、
	Adam B. Levine 、