--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/875zcs28ao.fsf%40dustycloud.org.
Suspect it was inspired by the Hyper-Text Transport Protocol.
And it had nothing to do with the other kind of TP that stores ran into shortage of.
-Baldur
What happens when multiple vats/machines resolve the same resolver?
What's next, assuming I keep sending messages about these
=========================================================
Hi, do you hate this thread yet?
I've left some things I'm uncertain about above. Thoughts welcome.
I'll also share more as I implement, assuming people are open to me
continuing to do so on this list.
I think in an upcoming email I may try to break down some of the common
message types sent in CapTP... that might help me think about what *I*
should implement, too.
But I guess we'll see... what do you think? Is this, and subsequent
similar, message(s) worthwhile/welcome?
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/84f78024-69ff-4d2d-9542-e0dc00dbe288%40googlegroups.com.
On Mon, May 18, 2020 at 2:25 PM Christopher Lemmer Webber <cwe...@dustycloud.org> wrote:What happens when multiple vats/machines resolve the same resolver?Within CapTP, a reference to a resolver is, I believe, never handed off to another machine, so this case can't arise, but I don't remember exactly how the 3-party-introduction operates.However, CapTP in E is built on top of a local promise system that does expose resolvers for general use, and the question does arise there (not specific to multiple machines). In that case, all implementations have been "the first to resolve wins", since it would be Bad if a resolved promise changed targets. However, there is one other question: what does the loser of the race see?
1. E chose to throw an exception in response to the second resolve() message to indicate that there was a probable bug.2. Waterken chose to silently do nothing, on the grounds that that way a resolver is a purely write-only communication channel — the holder of a resolver cannot learn whether someone else already used it.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANkSj9U3BipqdQj5M%2Bh7Kb_fSzr6Yn5B_rfHxg-fxLCpk8KgbQ%40mail.gmail.com.
On 19 May 2020, at 10:15, William ML Leslie <william.l...@gmail.com> wrote:On Tue, 19 May 2020 at 18:42, Matt Rice <rat...@gmail.com> wrote:
On Mon, May 18, 2020 at 9:25 PM Christopher Lemmer Webber
<cwe...@dustycloud.org> wrote:There's no need to layer a complex (and more insecure) security
architecture on top of our programming languages because the way
programmers already program, if we take it seriously, already *is* our
programming model:
This seems like you wanted to say "already *is* our security model",
otherwise it seems somewhat tautological.
https://xkcd.com/703/
I also think "on top of our programming languages", should really be
"on top of memory safe programming languages".
I understood "on top of our programming languages" to be an indictment of this:
https://docs.oracle.com/javase/7/docs/api/java/lang/SecurityManager.html
the Java SecurityManager has been a massive footgun and attempts at
using it rather than paring everything down to capability semantics is
the main reason that having a java client installed (or worse, having
the web plugin installed) is considered a security risk. People like
to quibble about versions, but putting band-aids on a sieve won't
quickly make it waterproof.
Java is primarily an object-capability language. SecurityManager
checks should be considered a last resort. Perform security checks at a few defined points and return an object (a capability) that client code retains so that no further permission checks are required.
Although Java is largely an object-capability language, a stack-based access control mechanism is used to securely provide more conventional APIs.
The main thing I'm unsure of (which surprisingly nobody commented on!)
is whether or not the imports/exports tables live on the Machine layer
or on the Vat layer. We'll see via implementation, I guess... I see
advantages to both.
> Now let's revisit with Alice in VatA and Bob in VatB. To Alice, the local
> proxy for bob is the decider. To VatA, VatB is the decider. To VatB, Bob is
> the decider.
>
> When Alice then does one of
>
> p~.bar()
> E(p).bar() // no sugar
> p <- bar() // E
>
> where should the message go? After all, we don't know where the object is
> that p will designate. It might even be on VatA. However, the unambiguously
> best answer is "send it to the decider". The steps by which it will come to
> be determined where that object is starts with the decision made by the
> decider. Therefore, if bar() needs to be routed elsewhere, that will be
> known at the decider before it is known anywhere else.
I'm actually not too concerned from the perspective of Alice at the
moment. Let's say that, in theory, something goofy happened... Vat A
actually sent messages to two different vats. Bob on Vat B and Carol on
Vat C are now both "the decider" and are ready to do something under the
assumption that they're the ones who resolve that promise.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87367w19kb.fsf%40dustycloud.org.
Mark S. Miller writes:
> The questions/answers table is the bookkeeping to do this backwards-in-time
> passing of the promise from VatB to VatA. VatA on sending the message knows
> that VatB, on receiving it, will create a promise/resolver pair. What would
> happen if VatB would send the promise part to VatA? Whatever bookkeeping
> that is, just set it up ahead of time.
>
> Again, that's why we don't make any special case for passing a resolver as
> argument. The receiver just received a remote reference to the resolver,
> with no reason to believe that it holds it exclusively. It may be in a race
> to resolve the resolver. It is not the decider.
Let's see if I understand what you're saying here by repeating it back
in my own words, and find out how wrong they are. :)
"In a first class promise-resolver pair, it is possible that multiple
entities may have access to the resolver, and the first one "wins".
But for promise pipelining, we need a stronger understanding: even
though we *could* just point to an arbitrary resolver, when something
is sent over in the questions/answers tables, it's an indication from
the other side that the vat responsible for answering is the one and
only decider. If we instead just pointed at an arbitrary exported
resolver, we aren't making as strong of a commitment... and promise
pipelining really needs that kind of commitment to work."
How far away is this from your thinking?
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87d06yzhyf.fsf%40dustycloud.org.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87d06yzhyf.fsf%40dustycloud.org.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/159000127524.955.5347742141363009481%40localhost.localdomain.
- Drivers are just conceptually two-faceted objects: half are whatother objects use to talk to the driver, and half are what the driveruses to talk to the special resource (filesystem, file, audio system,image system, etc).
-Ian
> Waterken automatically ignores a message received more than once, but you
> can't do that with devices unless the operations are idempotent. While you
> can turn many non-idempotent messages into idempotent ones, e.g., change
> "launch rocket" to "launch rocket #4," there are many you cannot, such as
> printing on paper. In your case, I think anything the user sees cannot be
> considered idempotent.
I think that's right but is something I haven't thought about
sufficiently... I will try to lend it more braincells. Thanks for your
useful comments.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/871rneywu6.fsf%40dustycloud.org.
So, here I am doing my first toy CapTP implementation. I said I'd use
this thread to document things I realize while I'm doing it. I think I
understand something now that I didn't before.
For whatever reason, I expected that the way that captp would work would
be you'd say "I'm exporting something for you now!" even in the two-vat
communication case. I was confused that when Vat A adds something to
their exports table, there was no "Exporting" or etc message type sent
to add something to Vat B's imports table. (There's "Provide", but that
appears to be for 3-vat introductions.)
Then I realized: it would be foolish to allocate an object import that
is unused in a weakmap. That's a fine path to it being immediately
GC'ed.
This solved another mystery for me. Why, in captp.js, was the
marshaling constructor called like so:
const { serialize, unserialize } = makeMarshal(
convertValToSlot,
convertSlotToVal,
);
This confused me because those seemed like side-effectful operations.
Why would you perform a hashmap-mutating operation at serialization
time? And the answer is the same as above: capability references will
be nested in the structure so the right time to set them up is during
serialization/deserialization. Hence passing in the side-effectful
functions into makeMarshal.
So, assuming I'm right, finally I understand that.
Sorry, this is probably obvious to all of you by now by having been over
it however many times yourself. But I'm the CapTP noob, so capturing my
realizations as I hit them. :)
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87v9kpxbn5.fsf%40dustycloud.org.
Mark S. Miller <ma...@agoric.com> wrote:> E made a mistake here. Tyler got it right. A turn that does not complete must have no external effects. We're getting that right at Agoric,I consider that choice to be more a design decision than a mistake. While Tyler's approach is better for recovery from vat failure, it adds latency to message delivery and forces a trade-off between message latency and turn duration. The E approach may be a better choice if you're latency sensitive, and vat failures are rare. For example, the parallel chess program I developed with waterken had all the vats on the same machine, so failure of a single vat was a bug. Performance was dreadful, in part because of waiting to the end of the turn to release messages.
A project I was working on at HP Labs attempted to have the best of both worlds. The idea was to release messages during a turn but mark them so their effects could be undone should the sending vat fail. We got pretty far, but the key person on the team left HP before we finished.
--------------
Alan Karp
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3OsbU-sqXQpbsPFy0dVQ3_MTvc%2BJu7fr7OBMagTCZ5cw%40mail.gmail.com.
On Fri, May 22, 2020 at 8:29 AM Alan Karp <alan...@gmail.com> wrote:Mark S. Miller <ma...@agoric.com> wrote:> E made a mistake here. Tyler got it right. A turn that does not complete must have no external effects. We're getting that right at Agoric,I consider that choice to be more a design decision than a mistake. While Tyler's approach is better for recovery from vat failure, it adds latency to message delivery and forces a trade-off between message latency and turn duration. The E approach may be a better choice if you're latency sensitive, and vat failures are rare. For example, the parallel chess program I developed with waterken had all the vats on the same machine, so failure of a single vat was a bug. Performance was dreadful, in part because of waiting to the end of the turn to release messages.The tradeoff makes sense, but a better way to address it is short turns.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANkSj9VqJ8Ys_4FizJm_%2BwoV1-Yz6MpuJe3bqcrL6uxn3nmQcA%40mail.gmail.com.
On Fri, May 22, 2020 at 9:58 AM Kevin Reid <kpr...@switchb.org> wrote:You could also have specialized types of vats, e.g. one which is for performing "heavy" "streaming" computation where you really do care about getting outputs fast while expressing the computation in a fashion not broken into turns, at the cost of those vats having no persistence — if they experience a failure they're permanently dead, and have to be rebuilt by other, transactional, vats that manage them.It is worth noting that such an exemption for ephemeral vats is not transparent. Without this change, an ephemeral vat is not observably different than a persistent vat that becomes inaccessible forever. With this change, even a turn that always aborts of not terminate, because of its code rather than an exogenous crash, would be sent from an ephemeral vat. This introduces a significant non-uniformity to the computational model for IMO little compensating benefit, and so should not be done *merely* because the sending vat is ephemeral. At least some additional step should be required to enable this special early release of messages.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANkSj9Wnq022eYTx8rHpwBsDAq4CkXUUzOHpofMyAj4n1itgXw%40mail.gmail.com.
IMO, for such distributed systems, the bookkeeping needed for speculation and distributed rollback is just not worth it. Go pessimistic, don't release messages from uncommitted state, and reduce latency by short turns and low-latency non-volatile memory. This is another thing that Waterken got right that E got wrong.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z0suGkW4Kiue3RJDysa7H%3DwUU9AOAfPsanG3Y7VG2qhaA%40mail.gmail.com.
Then I understood that they are in, jhu-paper sense, object graph exits in the serialized object graph depiction.
The confusion arose because in E slots are objects
where values of constants, variables, and such are
kept.
Any spefic reason why graph exits as above got called slots in Agoric's codebase?
-Baldur
One could say that similarly this is #:reckless-sends?. In both cases,I think making clear to the user that something truly dangerous is goingon, especially if users don't realize that it could mess uptransactionality when it matters (eg transactionality saves a mint andits purses from getting accidentally corrupted).
… "from a security perspective, a misbehaving vat outside of your trusted runtime can be treated the same way conceptually as one large and opaque misbehaving object". (I'm sure it was said more elegantly than that, but there's the idea.
This is a good and powerful idea, and I think I'd like to expand on that. Where are the borders of this encapsulation?
… Here's a proposition, and it may be false: a machine is the actual perimeter and communication boundary from the perspective of a networked environment. Vats are an important concept, but they're more important, mostly, from the perspective within the machine and otherwise from a conceptual model of the network.
In SwingSet, drivers are a special kind of vat because it's convenient.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/877dwzyh9k.fsf%40dustycloud.org.
Continuing with the "document revelations as I get them", I finally
think I understand E-Order, thanks to Baldur's patient explaining in the
#erights channel on irc.freenode.net. E-Order was one of the last
remaining things that gave me a sense of terror: it seems so
conceptually tricky to get right, but now I see that it's really quite
simple... Baldur is right: it does flow out naturally from the design!
> Fortunately, the WormholeOp is only terrifying if we start, as E does, from
> a TLS-like connection-oriented approach to cryptographic authenticity. When
> starting from messages as individually signed certs, wormholing "simply"
> becomes the need to carry a cert chain. This serves the same purpose as the
> cert chains of everything from SPKI/SDSI to zcap-ld, but are much cheaper
> because the A-to-B message carrying a reference to Carol only needs to
> include dependent *unacknowledged* A-to-C messages. As acknowledgements are
> received, the buffer of messages that need wormholing keeps
> shrinking, approaching zero under quiescence. This is a huge deal compared
> to other cert-chain authorization systems like SPKI/SDSI...zcap-ld.
Is the reason this preserve eq?-ness because in certificate systems, we
can transparently traverse to the root to find the more universal
identity of the object?
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87zh9vwviv.fsf%40dustycloud.org.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87zh9vwviv.fsf%40dustycloud.org.
So, starting with this example again:
// alice's perspective
carol~.x()
bob~.y(carol)
carol~.z()
// bob, after getting carol
carol~.w()
When Vat A gives Vat B access to Carol on Vat C, there is a
pre-requisite message that Vat A needs to be delivered *first*, the
carol~.x() called by Alice. But just in case Vat B beats Vat A to it,
we encode that same message in such a way that Vat B can deliver it so
Vat B doesn't have to "wait on" Vat A talking to Vat C.
The key other requirement: to preserve Vat B not intentionally breaking
E-order, this use of Carol is "unlocked" *by the delivery of Alice's
carol~.x() call*... but the wormhole op is a idempotent way of
Vat B delivering that message so that Vat B doesn't need to wait.
That's brilliant and I finally get it.
And I agree it can be better done with certificates!
I also think this certificate-like way of doing things can also be
ported to a TLS-like connection (well, disconnects may make things
tricky). But that's not a discussion of immediate concern.
- Chris
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87sgfmwu0p.fsf%40dustycloud.org.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/87k10ywnky.fsf%40dustycloud.org.
I find "TP" for "transport protocol" in the computer networks
sense in a google books search going back to about 1977. SMTP
(RFC 788, Postel 1981) was the killer app TP, I believe.
Don't forget ftp. Actually, feel free to forget it ;)
On Mon, May 18, 2020 at 4:02 PM Baldur Jóhannsson <zaru...@gmail.com> wrote:
True Paper! No, seriously, it stands for Transport Protocol.
Suspect it was inspired by the Hyper-Text Transport Protocol.
And it had nothing to do with the other kind of TP that stores ran into shortage of.
-Baldur
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/84f78024-69ff-4d2d-9542-e0dc00dbe288%40googlegroups.com.
--
Cheers,
--MarkM
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAK5yZYj5xT3u5aHb7Edf_XxkK1gyz7p1x9gFDRsKKMOfXGpfSw%40mail.gmail.com.
But hey, maybe you want that extra step... sturdy refs seem kind of
quasi-dangerous and I'd love to know where in my system I'm using
them.