Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

>
> Considering both exist in the same browser instance, that is a
> mind-bogglingly unnecessary detour.


You were right *up to that point*, then took a detour. :-)
There is nothing here that *assumes* a shared cloud-infrastructure. That's
just *one* example of how you could use this.
You can perfectly well use the token to establish communication over
BroadcastChannel with a same-origin application. A token is still necessary
because you'd not know which of several tabs you're capturing.
Collaboration with cross-origin applications is also possible using this
method if you embed a frame from the same cross-origin and ask it to relay
messages on your behalf.
HTH

On Wed, Jun 16, 2021 at 2:18 PM Lennart Grahl <lennart.grahl@gmail.com>
wrote:

>
>
> On 16/06/2021 12:30, T H Panton wrote:
> > Ha, I see the problem now, I’ve got comfortable in a flat-unique
> > token-namespace and forgotten how ugly the outside world is!
> >
> > I’m afraid this tells me that the idea of just having a token doesn’t
> > work - we need to define a namespace to assign meaning to it. I have
> > a couple of possibles in mind. The simplest being MDNS - you look up
> > the token in MDNS and retrieve an SRV which tells you how to
> > connect.
>
> I think you folks are talking at cross-purposes.
>
> IIRC, and please correct me if I'm wrong, this proposal is about
> **capturing a tab from the same browser instance**. And that is
> important. If we go beyond that (capturing a native app / window), all
> of a sudden we're in OS territory and have a whole number of different
> issues raising the barrier quite significantly as it would require
> specifying a communication channel between native apps (capturee) and
> browser (capturer) across different OSes.
>
> This is my summary of the spec so far and, again, correct me if I'm wrong:
>
> - it only targets **capturing a tab from the same browser instance**
> - the *handle* is just some arbitrary data unidirectionally exposed by
> the capturee for access by the capturer
> - the *permittedOrigins* limit access to the *token* by the capturer to
> the specified origins
> - *exposeOrigin* defines whether the capturer can see the origin it is
> capturing. (I'm not sold on having this btw. If you've got permission
> from the UA to capture, why would you need to hide the origin?)
>
> IIRC, what you (Google) are trying to do is to send a token from
> capturee to capturer that allows you to connect to some server the
> capturee is also connected to which in turn allows to remote control the
> capturee from the capturer. Considering both exist in the same browser
> instance, that is a mind-bogglingly unnecessary detour. What you
> actually want is a bidirectional communication channel between capturee
> and capturer.
>
> That brings me back to Sergio's proposal: Instead of *handle*, use a
> MessageChannel where one side gets port1 and one side gets port2. In code:
>
> dictionary CaptureHandleConfig {
>   boolean exposeOrigin = false;
>   port: MessagePort;
> }
>
> interface CaptureHandle {
>   [...
>   port: MessagePort;
> }
>
> If desired, that proposal could be refined with a mechanism from
> WebSocket, the subprotocol negotiation mechanism. This would allow to
> negotiate a (sub)protocol between both sides in a very simple manner, so
> both sides know how to communicate with each other.
>
> Now, if for some reason you still want to connect capturee and capturer
> via a third party (server), that's easily possible by just sending the
> data previously exposed via *handle* over the MessageChannel.
>
> Regards
> Lennart
>
>