Re: Screensharing: Bootstrapping Collaboration between Capturer and Capturee

>
> 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?


It is not in the browser's mandate to force collaboration on unwilling
participants.
Jitsi will be able to set up first- and third-party collaborations just as
much as everyone else.

what this web API will create is an uneven playfield to VC applications.
>

This API open a door. If some players are quicker to move through these
doors, that is a legitimate advantage. For the slower players to demand
progress be slowed and the status quo be kept, is to attempt to compete
through kneecapping the competition - unsportsmanlike.

You might say you do not ask for doors to be kept barred, but rather for a
different door to be opened. If so, I'd respond - there are things Capture
Handle provides that alternatives would not provide. It makes sense for
browsers to open multiple doors here.

So Jitsi will have to implement google docs apis, ms office apis, to do
> basically the same? doesn't seem very scalable


   1. I still agree that a more presentation-focused API would also be
   useful. Operative word "also." The more general-purpose tool of Capture
   Handle has its place. Some collaborations are very specialized by nature,
   and scaling them is not necessary. Special-purpose collaborations set up at
   great expense between one application (Underwater-Photoshop-2000) and one
   VC application (Jitsi) at great expense, financed by one special customer
   (the Atlantis School of Underwater Economics).
   2. Official and unofficial protocols usually arise in such situations.
   The capture-handle exposed by service X could be a JSON which includes
   {protocol: "public-preso-2.3", id: "0x382abc42", ...}. That would make
   things quite scalable.

That's what I am concerned about, privileged actions that will allow
> certain VCs to have a better user experience than the competence.


I think we're talking about different types of "privileged" here.
Regardless of whether the VC application is Jitsi or Zoom, the document you
are capturing will not allow access to risky operations without
authenticating the user. Imagine you're capturing Github. Would they allow
remote browsing (via relaying keyboard+mouse events) to arbitrary
capturers? No, because that lets them delete repos, post embarrassing
messages, etc. It's too risky. They'll want some authentication.

If you want to do that, why not integrate the VC application into your
> document web page and not the other wise?


   1. The remote-editing example was just an example.
   2. I can still have plenty of UX, marketing, budgeting and other reasons
   to prefer a multi-tab experience.

A capture-sef: disabled property on the getDisplayMedia would prevent this
> as well.


I like it when a single tool can tackle many tasks. I am not as eager to
construct multiple single-use tools. Shipping anything on the Web takes a
very long time...

That part of the api could work as is, i am only against the privileged
> apis for certain domains.


The API is not privileged, but its applications can be. That is by design.
I am not upset when my password does not allow me to log into your email.

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.


It is unclear to me if it would see use, as applications might prove
unwilling to allow an arbitrary capturer to control them. I prefer to
discuss this other proposal separately. We have enough reason to pursue
both discussions in parallel.

On Thu, Jun 10, 2021 at 9:06 PM Sergio Garcia Murillo <
sergio.garcia.murillo@gmail.com> wrote:

>
>
> 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
>
>