Distributed EQ for Dr. SES?

[Mark Miller]

JF Paradis and Caridy Patino (cc'ed) are building a Realms shim that

a) Should support Frozen Realms, which should support rebuilding SES for modern JavaScript.

b) Will be subject to a serious security review, providing a base to establish some confidence on the SES to be built on top.

c) Is tested and works on Node as well as the browser.

Brad Meck (cc'ed) has implemented the Weak References proposal on Node, enabling us to rebuild something like the Q-Connection library of Kris Kowal (cc'ed), extending local promises onto the network, but with a degree of distributed gc that makes it practical. This sets us up to start rebuilding Dr. SES.

As we proceed to build Dr.SES, we'll need to build on a CapTP or Cap'n Proto -like cryptographic capability protocol (perhaps using Cap'n Proto itself, Kenton cc'ed), and need to decide what stance we should take on distributed EQ. Some relevant work since the Grant Matcher:

Retroactive Corroboration for the EQ-less Horton Protocol

https://marc.info/?l=cap-talk&m=120354506701604&w=4

The Left Hand of Equals

https://research.google.com/pubs/pub45576.html

What else?

The EQ issue comes up concretely is two questions:

1) can one build the Q.join operator described in 

https://research.google.com/pubs/pub40673.html

?

2) given two remote promises p and q that are eventually resolved to the same remote object, is

async function join(p, q) {

  const [farP, farQ] = await Promise.all([p, q]);

  if (Object.is(farP, farQ)) {

    return farP;

  } else {

    throw "not the same";

  }

}

a correct implementation of the specified Q.join operator? (Among objects, Object.is and === are equivalent, so don't worry about the difference here.) In other words, does remote EQ turn into local EQ among settled remote references (far references)?

Here, I assume a (Q-connection-like) extension of the JavaScript promise system over this cryptographic distributed capability protocol where a promise fulfilled to a remote object has as a local fulfillment a "far reference" which is *not* a thenable, and therefore not a promise, or even promise-like. This is (unfortunately) necessary for remote promises to play smoothly with the JavaScript promise API.

Beyond specifying that a far reference is not a thenable, we need only specify that Promise.resolve(farP) results in a pipelining remote promise fulfilled with the same remote object, in order for the infix ! (eventual send) syntax to work and pipeline on far references. This is because the infix ! syntax always does a Promise.resolve on its left argument. 

What else we might want to specify about the API of a far reference is an interesting question. Perhaps it should be a JavaScript Proxy? (Tom Van Cutsem cc'ed) Fortunately this is a separable question. My inclination is that a far reference be opaque-by-default, supporting only identity and this Promise.resolve behavior. But support Unum-like (pass-by-construction) behavior to be non-default behaviors of far references, such as eventually consistent cacheing.

As explained at https://www.youtube.com/watch?v=9WdbTucMaRo&t=1594s

Jorge Lopez (cc'ed) will be building Gravity on Dr. SES, so it would be good to settle some answers to these questions soon.

The E answer on both questions is "yes". The Joule language by Dean Tribble (cc'ed) would answer "no" to both. The left handed equality operator of James Noble (cc'ed) would answer "yes" to the first and "no" to the second.

Of the addressed email lists, friam is the most active, so I propose that this conversation continue there. Non-members of friam: For your messages to be posted, you'll either need to subscribe to friam, or send them your messages to me for me to forward to friam. Thanks.