Re: [w3c/ServiceWorker] Remove foreign fetch (#1188)

@jakearchibald I started writing and was having a hard time describing what I thinking clearly. So I wrote some pseudo code here. It shows more or less what I was hoping would be possible:

```js
async function sendMediaToPeer({ config, stream, from, to }) {
  // Create a peer connection
  const pc = new RTCPeerConnection(config);
  // Get user's video/audio stream
  const stream = await navigator.mediaDevices.getUserMedia({
    video: true,
    audio: true
  });
  // Do all the signaling with a foreign fetch service worker 🤞
  pc.onnegotiationneeded = async () => {
    // Create offer
    const offer = await pc.createOffer();
    // Add media stream
    pc.addStream(stream);
    await pc.setLocalDescription(offer);
    // Gather all ice candidates for simplified signaling
    while (true) {
      if (pc.iceGatheringState === "complete") break;
      await new Promise(f => setTimeout(f, 100));
    }
    // Send offer, gets intercepted by service worker
    // The worker can store the offer with the Cache API
    const res = await fetch(`${API_ROOT}/${from}/offers`, {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify({ to, offer })
    });
    if (!res.ok) throw new Error("Could not create offer");
    // The offer is now cached in the service worker so
    // We can just poll for answer from the intended peer
    // (They would use the service worker to post their answer)
    while (true) {
      const res = await fetch(`${API_ROOT}/${to}/answers`);
      const answer = await res.json();
      if (answer) {
        // Aaaand we're connected! :)
        pc.setRemoteDescription(answer);
        break;
      }
    }
  };
}
```

**tl;dr** It'd be pretty amazing, if all of the signaling between peers could be done in a serverless manner by relying on a common foreign fetch service worker storing offers/answer with ["a single, authoritative cache instance"](https://developers.google.com/web/updates/2016/09/foreign-fetch#background).

And the signaling code could obviously be even cleaner if the foreign fetch service worker also supported `onmessage()` and `Client.postMessage()`. It could almost be a replacement for WebSocket server at that point. But again, I'm not sure if I totally misunderstood what foreign fetch is intended for and capable of. Admittedly, this all just seems too good to be possible 😅.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1188#issuecomment-393980728