Fwd: Chat with [email protected]

Thomas, Kevin & I would like to thank you from prodding us into a
breakthrough simplification of CapTP prodded by your first question.
After the following chat, Kevin & I continued with a verbal
conversations whose insights we will be writing up at
<http://wiki.erights.org/wiki/The_lost_resolution_bug_isn%27t>. The
punch lines of these insights are:

* We decide that the Lost Resolution Bug
<http://www.erights.org/elib/equality/passing-rules.html#lost-resolution>
is a feature, not a bug ;). For reasons we did not previously
appreciate, this cannot ever be fixed, even with the WormholeOp
<http://www.erights.org/elib/distrib/captp/WormholeOp.html>.

* Since we no longer plan to ever solve the Lost Resolution feature
;), we no longer have any need for SwissHashes in the CapTP protocol.
SturdyRefs still need SwissNumbers of course. But object that are only
ever exported as live references no longer even need to be assigned
SwissNumber, also greatly reducing our hunger for new entropy.

* We also no longer have any need for Far3Desc or WormholeOp. They are
currently stubbed out. They should simply be removed.

* ConstMaps may have keys that are pass-by-proxy objects. Lost
Resolution means that a ConstMap containing far refs as keys, sent to
a third vat, will arrive as a promise that only resolves to a ConstMap
once it's keys become settled again. This requires an ability to
effectively to a whenSettled, which can mostly be coded in E. But one
problematic case to be explained and examined (non-transparent
potentially unsettled selfless objects) may require a new primitive.


---------- Forwarded message ----------
From: [email protected] <[email protected]>
Date: Fri, Aug 28, 2009 at 8:52 PM
Subject: Chat with [email protected]
To: [email protected]


7:10 PM kpreid: hello?
 me: hi!
7:15 PM kpreid: Any topics?
  It's that time of the week again.
7:16 PM me: I know. I was going to look at the recent e-lang thread
tonight. I saw there were questions for me.
 kpreid: ok
________________________________
16 minutes
7:33 PM kpreid: BTW, you have an IM status of "I am MarkM's status"...
 me: Yes, actually, that's my status' status.
________________________________
16 minutes
7:50 PM me: On the first question for me, from looking at the
E-on-Java implementation, it seems the swissHash is is only used for
the bad old EProxyResolver sameness comparison.
  What is it used for in your captp implementations?
7:52 PM kpreid: It is, in fact, not used. But since my captp
implementation is not well-tested especially on 3party stuff we should
not rely on that.
  Remember, my captp has never been actually used to communicate between vats.
 me: Not even your captp on E-on-CL?
7:53 PM kpreid: Right.
 me: ok. I'll look at the 3-party stuff some.
7:54 PM (vaguely) I do think I remember thinking it was needed there.
 kpreid: I think my captp assumes that since it's *New*FarDesc futhre
refs will be to the same object.
  That is, only one proxy will be constructed.
7:56 PM me: for 2 parties only, I'm confident that's correct.
8:00 PM http://www.erights.org/javadoc/net/captp/jcomm/CapTPConnection.html#getLookup%28org.erights.e.elib.tables.ConstList,java.lang.String,java.math.BigInteger,java.math.BigInteger,java.lang.Object%29
8:01 PM Only relevant in a system like your in which the lost
resolution bug has been fixed.
 kpreid: I HAVE NOT FIXED LOST RESOLUTION.
 me: s/your/yours/
 kpreid: I have only an idea about it.
 me: Ah.
  Still, only relevant in such a system. Stubbed out in E-on-Java.
8:02 PM kpreid: OK, relevant how?
8:03 PM OK, I seepartly. Far3desc is only used if WormholeOp is
available, right?
 me: VatB needs to unserialize the Far3Desc into a resolved reference
immediately, before hearing back from VatB.
  Yes.
 kpreid: Ah, so it has a swiss number which it looks up by the hash
8:04 PM me: I don't think that's the issue.
  If VatB already has a far ref to Carol on VatC, then VatB knows
Carol's swissHash but not her swissNumber.
8:05 PM However, the Far3Desc arriving from VatB has to unserialize
into the same far ref that vatB already has.
 kpreid: I was thinking that when VatB gets the Far3Desc, it hashes
the number and looks up the hasj in its own table.
8:06 PM me: Far3Desc has a swissHash, not a swissNumber.
 kpreid: Right, but you can hash the num to get the hash.
8:07 PM me: But in the live 3-party protocol, no one is assumed to
know the number, just the hash.
 kpreid: OK, I was confused...I thought getLookup used a SwissNumber
  But I see it does get a hash.
8:08 PM So where's the problem?
  Ah, the nonce should be sufficient?
  Oh. The swissHash is used to make sure identities are coherent, perhaps?
8:09 PM me: The nonce is sufficient to establish access once vatB
talks to VatC. The swissHash is used to ensure identities are coherent
immediately on arrival of the Far3Desc in VatB.
8:11 PM Nonce's grant access. SwissNumbers grant persistent access.
SwissHashes grant ability to claim sameness, for example, for a
capabilities-as-keys comparison based service on VatB.
 kpreid: SwissNumbers don't grant persistent access in general.
  The 3-vat protocol uses swiss numbers, doesn't it?
 me: This may be a bad design -- the swissHash may be granting more
access than it should. But that's what I was thinking.
8:12 PM kpreid: Well, swissnumber says you have access to the object.
And you can compute the shash from the snum. So the snum shouldn't be
authority-to-claim-to-be.
 me: No. Not since we switched to the nonce/table-based protocol.
 kpreid: the shash, I meant
 me: Yes, but only for Far3Desc. Promise3Desc doesn't carry a shash.
8:13 PM kpreid: Well, but that's wrong.
 me: Why?
 kpreid: I shouldn't be able to spoof an identity by knowing the hash...
  by knowing the snum (which implies knowing the shash) I mean
8:14 PM me: Why not?
________________________________
5 minutes
8:20 PM me: I think this is a really important question. Even if you
have a half baked objection, please voice it because it may lead to a
genuine flaw. I am worried about this issue -- it's the "This may be a
bad design" I mention above.
 kpreid: Access to an object does not imply authority to be an object
  This is the swisshash/swissbase distinction.
  I mean, swissnum/swissbase.
8:21 PM me: Swissbase = authority to be the object.
  SwissNum = authority to access the object.
8:22 PM SwissHash = designation without authority -- the object's
identity without access to it.
8:23 PM The hard question that got me started on this: What is
serialized when you send a DisconnectedRef?
 kpreid: You yourself said "SwissHashes grant ability to claim sameness"
8:24 PM me: A DisconnectedRef should be somehow comparable to a far
ref to the same object, but it shouldn't give access to that object.
8:25 PM This also dates from before the proxy revolution, when I think
DisconnectedRefs and live FarRefs to the same object actually compared
as the same. Perhaps the whole thing needs to be rethought in light of
our more principled remote sameness story.
8:27 PM kpreid: I remember this discussion.
  FarRefs and Disc.Refs are not equal.
8:28 PM As long as you have a connection from you (say VatA) to VatB,
there is only one connection.
  So there is only one far ref, and it turns into a DisconnectedRef.
 me: Yes indeed it does need to be rethought. The newly arriving
Far3Desc cannot unserialize into a far ref that's the same as a
preexisting one, because if the nonce lookup fails, the arriving
farRef will break whereas the preexisting one won't.
 kpreid: (Only one far ref per remote object, I mean)
8:29 PM If you later reconnect, you get a Far ref which is not the
same as the previous Disconnected ref
  This scheme has all the properties we want, I believe.
8:30 PM Wait, what's wrong with the arriving ref broken, provided it
is unconnected rather than disconnected?
  After all, the nonce lookup failed = protocol error
 me: So here's the problem. Say we fixed the comm delay problem
causing the lost resolution bug. I don't care whether we fix it by
WormholeOp or otherwise.
8:31 PM At the moment a Far3Desc arrives from VatA, VatB does not yet
know whether the non-lookup will succeed. What does VatB create in the
meantime for delivery to Bob?
8:32 PM s/non/nonce/
 kpreid: Why does it not know?
 me: Requires a round trip to VatC that hasn't happened yet.
 kpreid: Oh, I see.
  Thinking.
8:34 PM So the problem is that VatA tells VatB about a VatC object
that may not even exist.
  Yes?
  ...that VatB doesn't know about already.
8:35 PM me: If vatB actually doesn't know about it, then there's no
problem, since there's no preexisting far reference that creates the
sameness dilemma.
8:36 PM If VatB doesn't already know alleged carol, then VatB can
immediately create a fresh far ref to deliver to Bob. It'll break once
the round trip completes, but that's ok.
8:38 PM kpreid: OK, that makes sense. That process doesn't require a
swisshash at all, right?
  We just lookup the nonce on VatC, and VatC can send an ImportDesc if
VatC already sent it out meantime.
8:39 PM Oh, but if VatB knows it...
 me: exactly. that's the problem
 kpreid: ponders
8:40 PM OK, answer this question alone: Given that VatB knows Carol,
how does VatA securely identify the existing B-ref-to-Carol in talking
to VatB, in ignorance of B's knowledge of Carol?
8:41 PM me: The present answer is the swissHash. "SwissHashes grant
ability to claim sameness"
8:42 PM kpreid: OK, by "claim sameness" you mean something unobvious.
  You mean "ability to claim I have the ref you have" apparently
 me: yes
8:43 PM kpreid: It sounds like "ability to claim my ref is the same as
some other ref"
 me: Again, this may be a bad design. I am worried about it.
  yes.
 kpreid: Please find better terminology
 me: Please help me do so ;)
8:46 PM Perhaps the right answer is to just kill Far3Desc and the need
for swiss hashes in captp, and just live with the lost resolution bug,
even if we were to do something WormholeOp-like.
 kpreid: Don't give up yet...
8:47 PM Got skype?
 me: I think so. Lots of computer reconfig. But let's try.
8:48 PM kpreid: I don't hear you.
 me: I can hear you
8:52 PM Skype just told me "connection lost"
 kpreid: Me too


-- 
Text by me above is hereby placed in the public domain

    Cheers,
    --MarkM