Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

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