W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2021

Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

From: Sergio Garcia Murillo <sergio.garcia.murillo@gmail.com>
Date: Thu, 10 Jun 2021 21:06:12 +0200
Message-ID: <CA+ag07ZdtG0BwLTUcTq2snvAqpx_Rw7Drbcz4dbiNbRUDn29HQ@mail.gmail.com>
To: Elad Alon <eladalon@google.com>
Cc: Youenn Fablet <youenn@apple.com>, WebRTC WG <public-webrtc@w3.org>
El jue, 10 jun 2021 a las 20:25, Elad Alon (<eladalon@google.com>) escribiĆ³:

> Hi Sergio,
>
> *Concerning Capture Handle:*
> The space of web-based VC applications is constantly growing, as is that
> of Web-based productivity suites. What's preventing Jitsi from using this
> feature to set up collaborations with applications like Google Docs, MS
> Office, or any other productivity suite?
>

That's not up to Jitsi to decide, but it will be up to google docs/ms
office to allow jitsi domains to communicate with them. Also, what will
happen with self-hosted jitsi servers that would have their own domains, or
not domains at all?



> What's preventing Jitsi from producing their own productivity suite and
> integrating with it using Capture Handle?
>

...


> No feature is equally useful to all players on the Web. Screen-capture is
> paramount to VC applications, but of little use to airline booking systems.
> Even if Capture Handle is more easily employed by entities who sit on both
> sides of the seesaw (capturer+capturee), that is not a valid argument
> against it. (a) The feature is still very useful for those who only sit on
> one side, so long as they collaborate with the other side. (b) The
> use-cases for those who sit on both sides are legitimate enough a need for
> us to support them.
>

The web apis are useful for an use case, what this web API will create is
an uneven playfield to VC applications. I am not against it per se, but
this should be clear to everyone and don't pretend otherwise.


>
> *Concerning the Actions
> <https://w3c.github.io/mediasession/#actions-model>-like alternative:*
> I think that's an interesting approach that could be explored in tandem.
> It provides a complementary set of capabilities for use-cases that benefit
> from the rails it offers, while other applications need the freedom of
> Capture Handle.
>
>    1. The Actions-like approach limits collaboration to a closed set of
>    predefined actions. The Capture-Handle-based approach bootstraps arbitrary
>    APIs.
>
> So Jitsi will have to implement google docs apis, ms office apis, to do
basically the same? doesn't seem very scalable

>
>    1. The Actions-like approach would not easily support non-trivial
>    authentication. What if the captured application has privileged actions to
>    expose?
>
> That's what I am concerned about, privileged actions that will allow
certain VCs to have a better user experience than the competence.

>
>    1. Would it expose it to any capturer? Or any capturer from a given
>    origin? Many applications will need more fine-grained access-control
>    (specific account, not just specific domain). Think remotely editing
>    content on the captured document. With Capture Handle, apps are free to use
>    any authentication method, as we only bootstrap their communication, we
>    don't serve as their telco.
>
> If you want to do that, why not integrate the VC application into your
document web page and not the other wise?

>
>    1. The Actions-based approach does not help detect self-capture and
>    its awful result - the hall-of-mirrors. Capture Handle does.
>
> A capture-sef: disabled property on the getDisplayMedia would prevent this
as well.

>
>    1. The Actions-based approach does not support discovery of captured
>    origin, which is useful for analytics - VC applications want to know what
>    their users share, so as to approach the right partners for collaboration
>    using Capture Handle. That is a legitimate use-case even if the analytics
>    gathered are incomplete due to lack of opt-in from some sites.
>
> That part of the api could work as is, i am only against the privileged
apis for certain domains.

To conclude this email (*not* the conversation šŸ˜œ):
> I hope to convince you that Capture Handle is very useful to Jitsi. If
> it's a bit more useful to X than to Jitsi, I don't think that's a valid
> complaint.
>

My concern is that it will provide no value to Jitsi but will help create
monopolies to VC+content providers.

I would be happy to collaborate in the future on complementary solutions
> that offer something similar, but with sufficient added value ("rails");
> the Actions-based approach you and Youenn have brought up sounds like that
> to me.
>

I think that the action based approach is a good way to go for the remote
presentation actions, let's see if we can get an agreement on the other
topics.

Best regards
Sergio
Received on Thursday, 10 June 2021 19:07:05 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 10 June 2021 19:07:29 UTC