Rough explaination of handoff plans below.

Initial conditions:

: .-------.        .-----.
: |   A   |        |  B  |
: |(Alice)--------->(Bob)|
: '---|---'        '-----'
:     \AC:imp:0       ?
:      \         .-------.
:       \        |   C   |
:        '------->(Carol)|
:        AC:exp:0'-------'


 - A and B have an open session.

 - A and C have an open session.

 - We do not know or assume whether B and C have an open session
   yet.

 - At the start of CapTP sessions, we either as part of handshake also
   show the "Handoff Key" we plan to use for this session, or we could
   introduce an op:get-handoff-key.

 - Alice on A has a reference to Bob on B and a reference to Carol on
   C.  We care, abstractly, about the object references, but really for
   CapTP purposes, what we *really* care about is that between A<->C,
   is that there is a pairwise import(A)/export(C) of Carol at slot 0.

 - Alice is trying to invoke Bob with Carol, like so:

     ;; Alice runs the following... <-np is a message send that does
     ;; not request a promise for its result
     (<-np bob "foo" carol "bar")

 - Thus we have the following roles:
   - A: gifter:   A is gifting to B something they have on C
   - B: receiver: B is the recipient of A's gift
   - C: exporter: C already exports to A, will now also export to B

 - Between A<->B, this looks like the following (syntax roughly
   Preserves-style, with custom records):

#+BEGIN_SRC racket
  <op:deliver-only
     ;; to-desc: the recipient of this message
     ;;   (Bob, import(A)/export(B) slot 33)
     33   
     ;; args: arguments to apply
     ["foo"
      <desc:handoff-give-envelope
        ;; the handoff certificate to be signed
        <desc:handoff-give
          ;; recipient-key: handoff signing key this is being given to
          #base64{RECIPIENT-HANDOFF-KEY}
          ;; exporter-location(-hint(s)): how to connect to get this
          ;;   NOTE: See "VapTP crossover suffering" described below
          <desc:ocap-machine-uri ...>
          ;; exporter-session: which session at the location
          #base64{AC-SESSION-NAME-HERE}
          ;; exporter-side: which "named side" of the session is the exporter
          ;;   This might be the exporter's... generalized handoff key.
          ;;   Or the "half" the exporter had contributed to the session
          ;;   they have with the gifter.
          #base64{AC-SOMETHING-IDENTIFYING-C}
          ;; give-export: import the "gifter" is sharing with the
          ;;   "receiver", named from the "exporter"'s PoV
          0   ; CtoA export of Carol
          ;; after-answer: (OPTIONAL?: for E-order)
          ;;   exporter only gifts after answering answer for gifter
          ;;   greater than or equal to this number
          22
          ;; release-answer: Exporter fulfills promise to gifter at this
          ;;   answer number with anything (triggers release of vine)
          23>
        ;; signature by gifter (here: A)
        #base64{GIFTER-SIGNATURE-OF-CERTIFICATE}>]>
#+END_SRC

 - B now has this signed certificate by A permitting them access to
   Carol on C.

 - Should B deliver this message immediately to Bob?  Presumably yes,
   passing instead of Carol directly, a promise that will be fulfilled
   with Carol (sandwiched between the "foo" and "bar" string arguments)

 - B now needs to establish a connection with C.  This is where the,
   ahem, "location hint(s)" come in.  Much suffering lives here,
   especially in the above.  In short, we suffer because:

   - Establishing a direct connection for sending messages is more or
     less a VatTP problem, but now VatTP has found its way into our
     CapTP.
     
   - Are these "hints" (eg in E) or really a true
     self-authenticating-designator (eg Tor Onion Services)?
     What if a vat is available through multiple "paths"?
     Does the exporter need to verify that this is what they
     believe to be an appropriate and acceptable path/location for
     them?

   - Am I being melodramatic about the creep of vattp identity?  Eek!
     (eq?!)

 - Now B has a connection to C, or reuses their existing connection to
   C.

 - Now, one might assume that at this point, B signs proof of
   invocation and presents it, and maybe that's fine.  However we
   might note that this might lead to a replay attack if this
   certificate were somehow intercepted, so the other option
   is...

 - B, upon presenting the certificate, is either given a challenge by
   C to sign with a nonce, or there's something equivalent
   (incrementing identifier for handoffs within this session of BtoC
   or something).
   Anyway, signed challenge is presented to C, along with a question
   number, which is wired to a resolver which will fulfill the promise
   handed to Bob.

 - C verifies all signatures make sense and are relevant.
   If after-answer is used (for e-order), resolve this *only after* we
   answer AtoC's after-answer id, or if not, proceed immediately.

 - C now can answer B's question presented alongside signed certificate
   for what the gift is, fulfilling with an export from CtoB.

 - Since B is now able to handle its own GC needs for Carol, C triggers
   release-answer, freeing the vine to Carol held on A.

... I think that's it.