Discovery

[rektide]

I would like to be able to advertise my ServiceWorker's willingness to be connected to. External/other-domained ServiceWorkerGlobalScopes should be able to elect to get notice of a connect-to URL that I broadcast to any receiving ServiceWorkerGlobalScopes.

This would deprecate my desire for a chrome.extensions.discovery capability.

[mkruisselbrink]

Discovery certainly seems like an interesting feature to have, and one that would enable all kinds of cool use-cases. I'm not sure if it makes much sense to include in this initial version of the spec though, since it would make things a lot more complicated. Presumably for a discovery service to be useful you don't just want to know all the services that are available, but you want to know what services implement some specific API. Something like this seems to be what you're proposing?

// service worker:
self.onactivate = function(e) {
  self.exposeService('/services/notify', 'com.rektide.Notify')
};
// other event handlers...

// client code:
navigator.getServices('com.rektide.Notify').then(
  function(services) {
    navigator.connect(services[0]).then(
      function(port) {
        // ....
      }
    );
  }
);

One reason to not include this in at least a first iteration of this spec is that most of this can actually be implemented using navigator.connect. You can implement your own discovery service as a navigator.connect exposed API (with a known URL); other services can then register with this discovery service, and clients can query the discovery service to get a list of services. Something like this (ignoring how to actually implement the discovery service and how to make sure the discovery service is available):

// service worker:
self.onactivate = function(e) {
  e.waitUntil(navigator.connect('https://rektide.com/discoveryservice/register').then(
    function(port) {
      port.postMessage({url: 'https://example.com/services/notify', action: 'com.rektide.Notify'});
    }
  ));
};
// other event handlers...

// client code:
navigator.connect('https://rektide.com/discoveryservice/lookup').then(
  function(discoveryPort) {
    discoveryPort.postMessage({action: 'com.rektide.Notify'});
    discoveryPort.onmessage = function(event) {
      var services = event.data.services;
      navigator.connect(services[0]).then(
        function(port) {
          // ....
        }
      );
    };
  }
);

(and all that extra boilerplate could of course be wrapped in convenience methods).

[rektide]

My polyfill will indeed take such a tactic of implementing a "well known" interchange where services and clients can discovery each other.

You can implement your own discovery service as a navigator.connect exposed API

There are two hard-fast prerequisites created by "discovery" not being a baked in capability of the user-agent:

1. The "discovery" code has to be loaded, meaning either sending the user to potentially a 3rd party site to install the connect-able discovery service-worker or creating one's own unique discovery endpoint
2. Anyone clients/services wishing to participate in discovery have to rendezvous at a well known "discovery" endpoint.

Hosted discovery isn't discovery: it's the formation of a registry, precisely because it can not be discovered, only queried. Eliminating the requirement for asking well-known URL's is what we need the user-agent to assist with.

I can understand not pushing this in v1.0, but I have some trepidation as I don't know who what when or how any follow-up work would occur. This is important to me, it's important to the web, but I have no awareness of anyone else that would champion this important leap, a leap that would take us from an offline Service-Worker web to one where the User-Agent can throw open the gates & create a new Agent-Local connected cohesiveness for the web. Connect is a bolt from the blue, one of the truly great deployabilities and articulations of ServiceWorkers that pulls things together, but I don't know very much about the context that it sprang from. I've asked in the mailing list for background information on Connect's origins, which would help give me a better picture to understand what I need to do to champion this vital web-weaving twist on it.

[rektide]

I'm seeing a lot of similar vibes coming off of BroadcastChannel. It's just the multicast to navigator-connect's unicast, but multicast underlies a lot of service discovery technologies.

Using BroadcastChannel for discovery would pose all the same challenges faced here- the need to coordinate discovery ahead of time on a well-known channel name. And further, a service advertising on a well known discovery channel would have to take the additional responsibility of sending advertisements periodically.

[rektide]

Oh, hey, as far as implementing the web page's "tell me who has registered to be discoverable" side of discoverability, I'd love to see that happen as an extension to Device API's Network Discovery spec.