Loading ...
Sorry, an error occurred while loading the content.
 

Interconnect

Expand Messages
  • Douglas Crockford
    We now have two webvats, the HTML frame or iframe, and the Gears s worker pool. What we need next is a safe common way to let them communicate. I think that
    Message 1 of 3 , Jun 5, 2007
      We now have two webvats, the HTML frame or iframe, and the Gears's
      worker pool. What we need next is a safe common way to let them
      communicate.

      I think that takes the form of some kind of vat manager, which assigns
      unique, unguessable IDs to each vat, and routes messages which are
      addressed with those IDs. The messages can be represented as JSON
      texts, so the messaging will not cause capability leakage.

      What other services should the vat manager provide? Should it mark
      every message with a return address? Should it provide location
      services for vats sharing a common domain, or must such discovery be
      done through the server? Should it send disconnection messages when it
      sees vats disappear to correspondents of those vats?
    • Tyler Close
      ... Typically, we don t do access control at the vat level, but at the reference level. Typically, the vat identifier is just a self-authenticating identifier,
      Message 2 of 3 , Jun 5, 2007
        On 6/5/07, Douglas Crockford <douglas@...> wrote:
        > I think that takes the form of some kind of vat manager, which assigns
        > unique, unguessable IDs to each vat, and routes messages which are
        > addressed with those IDs.

        Typically, we don't do access control at the vat level, but at the
        reference level. Typically, the vat identifier is just a
        self-authenticating identifier, like a fingerprint of the Vat's public
        key. Since the communication channels in this case are local, we don't
        need crypto to secure them, so really, any old string is perfectly
        fine as a vat identifier. This is fortunate, since the Gears API
        doesn't seem to give us any control over the worker ID.

        Looking at the Gears API, it also appears that the messaging system
        does not allow forging of the sender's worker ID. If this is so, we
        can implement an actual object-capability protocol, using a per-sender
        clist, and so we won't need any crypto at all. Each worker keeps a
        clist for each of its clients and an inter-Vat reference is just the
        pair ( worker ID, clist index). It seems likely that we could borrow a
        lot of the design of E's CapTP protocol for managing these clists.

        Tyler

        --
        The web-calculus is the union of REST and capability-based security:
        http://www.waterken.com/dev/Web/

        Name your trusted sites to distinguish them from phishing sites.
        https://addons.mozilla.org/firefox/957/
      • Douglas Crockford
        ... Naturally. One of the peculiar aspects of widget architecture is that you have multiple vats that represent a common interest, but which initially have no
        Message 3 of 3 , Jun 7, 2007
          > Typically, we don't do access control at the vat level, but at the
          > reference level. Typically, the vat identifier is just a
          > self-authenticating identifier, like a fingerprint of the Vat's public
          > key. Since the communication channels in this case are local, we don't
          > need crypto to secure them, so really, any old string is perfectly
          > fine as a vat identifier. This is fortunate, since the Gears API
          > doesn't seem to give us any control over the worker ID.

          Naturally. One of the peculiar aspects of widget architecture is that
          you have multiple vats that represent a common interest, but which
          initially have no knowledge of each other, which want to communicate,
          but cannot rely on the page to do the introduction.

          They could manage the introduction through their common server, but
          that will add a couple of roundtrips to the startup time, something
          we'd like to avoid.

          An alternative would be if the vat manager could facilitate such
          introductions. For example, it could accept requests of the form:
          Please introduce me to all of the services that were vended from the
          same domain as myself.
        Your message has been successfully submitted and would be delivered to recipients shortly.