Re: [webrtc-pc] Permission API for receive-only media and data use cases (#2175)

> UX is hard, and there may be other ways to handle that.
Having this permission surfacing as a web concept might be a good idea.

Exactly. UX is best left to user agents to  explore; whether modal or something like Firefox's block-first config-like autoplay permission—or even ignore it—works best for them. There's likely not one right answer here. But this PR works with all of these models, so we don't block on UX.

I think what blocks experimentation today, is no-one wants prompts on all mode 3 WebRTC calls ahead of gUM.

The two critical parts I see addressed by this PR are:
 1. User agents today have no way to distinguish an app that is content with mode 3 from one that would suffer a prompt.
 2. User agents have no mechanism to inform an app that its trust level has increased after it has connected.

> > adding this permission might actually help free initial connection from being behind a permission prompt.
>
> I also somehow like this idea.
> At the same time, web developers can already do it now.
> If they do not do it, maybe that is not such a big user experience issue.

True, though given the complexity of just [getting negotiation right](https://blog.mozilla.org/webrtc/perfect-negotiation-in-webrtc/) in all browsers today, I wouldn't read too much into the lack of experimentation in the negotiation realm just yet.

I do hear people find the tight coupling between `getUserMedia` and peer connections troubling.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2175#issuecomment-499984610 using your GitHub account

Received on Friday, 7 June 2019 18:08:25 UTC