15:54:50 <RRSAgent> RRSAgent has joined #webrtc
15:54:50 <RRSAgent> logging to https://www.w3.org/2022/01/18-webrtc-irc
15:54:53 <Zakim> Zakim has joined #webrtc
16:02:33 <dom> Recording is starting
16:02:56 <dom> Agenda: https://www.w3.org/2011/04/webrtc/wiki/January_18_2022
16:03:22 <steely_glint> steely_glint has joined #webrtc
16:04:11 <dom> Scribe+
16:04:27 <dom> Slideset: https://lists.w3.org/Archives/Public/www-archive/2022Jan/att-0002/WEBRTCWG-2022-01-18.pdf
16:04:50 <dom> Topci: Recent CfAs and CfCs
16:04:56 <dom> [slide 8]
16:05:07 <dom> s/Topci/Topic/
16:05:24 <dom> Bernard: Region capture now adopted with repo in w3c org
16:05:25 <dom> [slide 9]
16:05:56 <dom> Topic: Agenda review
16:05:58 <dom> [slide 10]
16:06:15 <dom> Topic: WebRTC NV Use Cases
16:06:17 <dom> Repo: https://github.com/w3c/webrtc-nv-use-cases/
16:06:38 <dom> TimP: PR #73 to update the use cases based on the December discussions, now merged
16:06:49 <dom> ... there may needs new requirements, currently place holders
16:06:55 <dom> ... please look at the PR and comment on it
16:07:22 <dom> ... last time we talked about decentralized messaging and came to the conclusion we needed input from practionner in that space
16:07:43 <dom> ... I've invited Kegan to provide input based on his experience
16:07:55 <dom> [slide 13]
16:08:18 <dom> Kegan: I work at Matrix, will start with some context before going into WebRTC & service worker
16:08:49 <dom> ... matrix has voice support which uses WebRTC in the browser, based on matrix signalling
16:09:03 <dom> Present+ Harald, Youenn, TimP, Bernard, Jan-Ivar, Kegan, Dom
16:09:06 <dom> [slide 14]
16:09:29 <dom> Present+ Carine, Guido, Elad, TonyHerre, BenWagner
16:10:06 <dom> Kegan: because webrtc can't run in a service worker, we rely on web sockets proxy through a central server
16:10:18 <dom> ... in 2021, we developed our own overlay network, Pinecone
16:10:55 <dom> ... limited in which nodes a browser can directly connect to due to limitation of WebRTC in service workers
16:10:58 <dom> [slide 16]
16:11:28 <dom> i/... in 2021/[slide 15]
16:12:10 <dom> [slide 17]
16:12:23 <dom> Kegan: no need to run long-live process in the background - anti-goal
16:13:00 <dom> ... fetch can't work as an alternative to webrtc due to discovery and comm with local nodes
16:13:02 <dom> [slide 18]
16:13:24 <dom> Kegan: any of the 4 listed proposals would work, I'm guessting B or C might be the easiest
16:14:18 <dom> Bernard: we've had proposals to have datachannels in workers, also peerconnection in workers
16:14:26 <dom> Kegan: that matches proposals C & D
16:14:35 <dom> ... making new connections would be preferable
16:14:45 <dom> ... might still be messy, but would be tractable
16:14:55 <dom> Bernard: any additional requirement for ICE?
16:15:02 <dom> Kegan: think what we have is enough at the moment
16:15:16 <dom> JIB: did you consider Shared Worker?
16:15:34 <dom> ... They allow to share between multiple tabs without being a Service Worker
16:15:47 <dom> ... I guess they can't outlive the last tab linked to them
16:15:55 <dom> ... but they may help remove some of the concerns with service worker
16:16:01 <dom> Kegan: sounds appealing indeed
16:16:12 <dom> ... also helps reduce duplicate computation
16:16:20 <dom> JIB: do you need outliving the last tab?
16:16:37 <dom> Kegan: not needed; would be useful, but we understand that it may not be reasonable given the lack of user visibility
16:16:42 <dom> JIB: so useful but not necessary
16:20:25 <dom> Youenn: you could create a PC in a shared worker, transfer it to a service worker which would intercept the fetches
16:20:29 <dom> Kegan: that sounds great
16:20:59 <dom> s/a peerconnection/a data channel/
16:21:33 <dom> TimP: do we need to special case transfer to SW for datachannel?
16:21:48 <dom> Youenn: the proposal on the table for datachannel is to make them transferable anywhere
16:22:03 <dom> ... this would add the need to create a peerconnection in any worker
16:22:18 <dom> JIB: or we could limit creation to shared worker
16:22:40 <dom> Youenn: a service worker not being a stable context makes it not a great target for long lived objections such as a PC
16:22:46 <dom> ... but there is probably no harm in allowing it
16:23:08 <dom> JIB: this may create concerns of having PC in service workers with no matching tabs
16:23:25 <dom> Youenn: this is already possible with fetch, in a very constrained set of situations
16:23:34 <dom> ... probably needs more evaluation
16:24:55 <dom> TimP: so in this scenario, could a push notif set off a cascade of updates?
16:25:16 <dom> Youenn: lots of reluctance in doing complex tasks without visible UI in a tab
16:25:38 <dom> Ben: re datachannels in service workers, is it possible to keep a datachannels for more than one request in a service worker?
16:26:02 <dom> Youenn: good point - that will depend on each browser re when they might kill a service worker, which is based on UA-dependent heuristics
16:26:09 <dom> ... that might make this tricky indeed
16:26:43 <dom> JIB: can data channels be transfered anywhere or just dedicatedworker?
16:26:50 <dom> Harald: we haven't specified it
16:26:56 <dom> Youenn: we have it in webrtc-extensions
16:27:05 <dom> Harald: transferability isn't specific to a type of worker AFAIK
16:27:29 <dom> Youenn: the datachannel interface is exposed in Worker which covers all type of workers
16:27:43 <dom> TimP: what's a sensible next step then?
16:28:39 <dom> Youenn: an issue should be raised on webrtc-extensions re creating PC in workers
16:28:52 <dom> Harald: I think we need an explainer that shows how it all fits together and what it enables
16:29:20 <dom> ... in webrtc-extensions
16:29:45 <dom> ... a mark down file with the a description of an implementation of a P2P use case, that describes the changes needed
16:29:47 <dom> youenn: +1
16:30:07 <dom> TimP: what impact on the use case?
16:30:18 <dom> ... currently has no associated requirements
16:30:52 <dom> Harald: might link to the explainer
16:31:06 <dom> Bernard: you could make a start based on what we've been talking about
16:31:42 <dom> JIB: maybe slide 16 can be boiled down to requirements
16:32:15 <dom> TimP: I can take the shot at the explainer
16:32:39 <dom> Kegan: will be happy to help
16:32:41 <dom> Harald: likewise
16:32:49 <dom> RRSAgent, draft minutes
16:32:49 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
16:32:59 <dom> Topic: Media Capture Transform
16:33:05 <dom> Repo: w3c/mediacapture-transform
16:33:16 <dom> [slide 21]
16:33:37 <dom> Harald: next step for this document is FPWD - it triggers licensing requirement based on W3C patent policy
16:34:04 <dom> ... in terms of requirements, FPWD doesn't require consensus, no W3C endorsement, but should document oustanding issues
16:34:28 <dom> [slide 23]
16:34:46 <dom> ... 9 open issues on the spec
16:34:48 <dom> [slide 24]
16:35:24 <dom> ... proposed dispositions for issue #4 (leave open for later)
16:35:31 <dom> ... #20 (adopt suggested text)
16:35:53 <dom> ... #23 (documented as issue in spec, leave open for later)
16:36:27 <dom> ... #26 - refocused on muted tracks, which the spec now addresses with an attribute suggested by Jan-Ivar - closed issue
16:36:31 <dom> [slide 25]
16:36:42 <dom> ... #29 documented in spec as issue, left open for alter
16:36:45 <dom> s/alter/later/
16:37:17 <dom> ... #30 memory locality - leave open, exploratory, not needed prior to FPWD
16:37:51 <dom> ... #34 relationship to WebGPU - also exploratory; WebCodecs has a proposed relationship to WebGPu that may help
16:38:08 <dom> ... #65 - feels like an issue on VideoFrame i.e. for WebCodecs
16:38:12 <dom> [slide 26]
16:38:28 <dom> Harald: I don't think we have any blocker to move to FPWD
16:38:43 <dom> ... I would like to propose we start a CfC after this call
16:39:06 <dom> JIB: +1 to your proposed issue disposition
16:39:35 <dom> ... I've opened issue #71 for an additional clarification remaining on audio processing
16:39:43 <dom> Harald: indeed a left over
16:40:07 <dom> Youenn: in the same vein, the use cases include audio, that probably should be updated
16:40:48 <dom> Harald: +1 on clearing out these pieces of audio remains
16:43:25 <dom> Youenn: would be good to remove these remains indeed
16:43:38 <dom> Harald: will make a PR toward that, and then we'll run the CfC
16:43:43 <dom> [slide 27]
16:44:06 <dom> Topic: WebRTC Extensions
16:44:11 <dom> Repo: w3c/webrtc-extensions
16:44:31 <dom> [slide 30]
16:44:32 <dom> Bernard: PR #125 add an api to request key frames with 3 end points
16:44:35 <dom> [slide 31]
16:44:49 <dom> Bernard: the CfC concluded yesterday, with a concern raised on synchronization
16:45:08 <dom> ... no timestamp returned compared to PR #37
16:45:43 <dom> ... and issue #127 raising the question to sync with key changes (e.g. when someone new joins a call)
16:46:15 <dom> ... any opinion on whether the timestamp from PR #37 matters?
16:46:29 <dom> Harald: it matters exactly for the described use case
16:46:42 <dom> Youenn: #127 is only about SFrameTransform not for ScriptTransform
16:46:54 <dom> ... ScriptTransform has access to all encoded frames
16:47:08 <dom> Harald: you know whether it's a keyframe, but not if it's the one you've asked for
16:47:44 <dom> Youenn: the only case where it matters is when you actually want to only apply encryption at the 2nd frame, not the 1st one
16:47:57 <dom> ... we don't need a timestamp for that, we can resolve a promise when the next read will be called
16:48:00 <dom> ... that's what in the PR
16:48:09 <dom> ... I don't know if that's enough, but it should be close
16:48:12 <dom> [slide 32]
16:48:26 <dom> Bernard: by the time the key frame is returned, it may already have been encrypted
16:48:40 <dom> ... could you promise.all the situation?
16:51:10 <dom> JIB: may be a footgun with a race condition; do we need the method on the Sender?
16:51:33 <dom> Youenn: the use case for that wasn't related to encryption, but e.g. a simulcast situation
16:51:42 <dom> ... no timestamp needed for that
16:52:03 <dom> Bernard: so we're willing to explore Promise.all vs an atomic method that generates a keyframe and set the keys
16:52:31 <dom> Youenn: for #127, we need to define a behavior for SFrameTransform for sure
16:52:46 <dom> Bernard: but not necessarily an atomic method?
16:53:43 <dom> Youenn: to be seen
16:53:57 <dom> ... but that can be done in a later iteration, shouldn't block #125
16:54:06 <dom> ... #127 is needed to ship SFrameTransform though
16:54:14 <dom> Topic: Capture Handle
16:54:28 <dom> Repo: https://github.com/WICG/capture-handle
16:54:32 <dom> [slide 35]
16:56:47 <dom> [slide 36]
16:57:36 <dom> Elad: previous proposal in this space assumed coordination between capturer and capturee
16:57:40 <dom> [slide 37]
16:59:14 <dom> [slide 38]
16:59:51 <dom> [slide 39]
17:00:25 <steely_glint> Scribe +
17:00:47 <dom> [slide 40]
17:00:57 <steely_glint> [Slide 40]
17:01:25 <steely_glint> [Slide 41]
17:02:24 <steely_glint> New proposal to allow more decoupled apps - not sharing common origin
17:02:33 <steely_glint> [slide 42]
17:04:21 <steely_glint> Dom: future is useful. Can it be more useful beyond capture-capturee use case ?
17:04:38 <steely_glint> Dom: propsal is useful. Can it be more useful beyond capture-capturee use case ?
17:05:06 <dom> s/future/feature/
17:05:25 <steely_glint> Dom: cf old 'web intent' proposal
17:05:48 <dom> -> https://paul.kinlan.me/reinventing-web-intents/ Reinventing Web Intents, Paul Kinlan 2017
17:06:15 <dom> -> https://en.wikipedia.org/wiki/Web_Intents Web Intents description on wikipedia
17:07:06 <steely_glint> youenn: MediaSession Handler API does something similar for play/pause
17:07:32 <steely_glint> Youenn: but the security context is different.
17:08:16 <steely_glint>  https://developer.mozilla.org/en-US/docs/Web/API/MediaSession/setActionHandler
17:09:07 <steely_glint> Elad: message can be sent by app, not just the user...
17:09:41 <steely_glint> Elad: The actions are different in this context
17:10:50 <steely_glint> Youenn: Media session API is not sufficient, but may be a good starting point.
17:11:15 <steely_glint> Jan-Ivar: NextTrack != NextSlide
17:11:39 <steely_glint> Jan-Ivar: Better off with separate APIs
17:12:35 <steely_glint> Jan-Ivar: Simple NextSlide PrevSlide is enough to start with.
17:14:17 <steely_glint> Harald: This is a more Generic interface - could Media session API be implemented in terms of the user defined actions in this proposal?
17:14:49 <steely_glint> Elad: Small set of predefined actions need limited collaboration.
17:15:24 <steely_glint> Elad: userdefined actions require deeper collaboration.
17:17:58 <steely_glint> Dom: Agree with Harald. Trade off between Generic all purpose API and solving this requirement.
17:18:31 <steely_glint> Jan-Ivar: No arbitrary Strings please.
17:19:32 <steely_glint> Elad: Do we agree we need both of these proposals ?
17:20:17 <steely_glint> Youenn: Both perhaps Different priorities.
17:20:32 <steely_glint> [Slide 43]
17:22:30 <steely_glint> Elad: without identification you can't do two way communications
17:24:02 <steely_glint> Elad: in terms of priorities the identification allows us to do everything so we should do it first.
17:25:11 <steely_glint> Jan-Ivar: Next-Prev is more friendly for new market entrants
17:25:36 <steely_glint> Youenn: Next-Prev is easier to deliver.
17:27:25 <steely_glint> Elad: We have had plenty of time to look at capture handle - it has been in an origin trial.
17:27:37 <steely_glint> Elad: for 6 months
17:28:58 <steely_glint> (somewhat lost the thread here)
17:29:07 <steely_glint> - Anyone chime in ?
17:31:46 <steely_glint> Harald: would like to decouple the issues so we can attach the concerns to the right parts.
17:32:43 <steely_glint> Youenn: Identity is a problem (and with origin)
17:32:59 <steely_glint> Elad: Would like to fast track the discussion
17:34:03 <steely_glint> Dom: We want to solve the use case - Jan-Ivar wants the narrow use case to drive the process.
17:34:54 <steely_glint> Dom: do we want to start an adoption process? Or do we want to specify some issues that need to resolve first?
17:36:09 <steely_glint> Elad: In sprit of compromise we can start with adding Actions
17:36:38 <steely_glint> Dom: can we start a call for adoption now?
17:37:57 <steely_glint> Youenn: will work on some GitHub issues.
17:39:00 <steely_glint> Dom: Call for adoption defines the scope of a document, not the precise content.
17:40:11 <dom> -> https://github.com/w3c/mediacapture-screen-share/issues/166 Previous discussion in this space
17:42:09 <dom> RESOLVED: We start a call for adoption of Capture Handle by the WG
17:43:00 <dom> i/[slice 27]/Resolved: Start a CfC for FPWD of Media Capture Transform after audio bits are removed
17:43:06 <dom> RRSAgent, draft minutes
17:43:06 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:43:17 <dom> RRSAgent, make log public
17:43:33 <dom> Meeting: WebRTC January 2022 meeting
17:43:40 <dom> Chairs: Harald, Bernard, Jan-Ivar
17:43:43 <dom> RRSAgent, make log public
17:43:45 <dom> RRSAgent, draft minutes
17:43:45 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:44:08 <dom> i/[slide 27]/Resolved: Start a CfC for FPWD of Media Capture Transform after audio bits are removed
17:44:10 <dom> RRSAgent, draft minutes
17:44:10 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
17:45:20 <dom> i/Harald: likewise/RESOLVED: update use case and start explainer in webrtc-extensions for changes needed to make WebRTC usable in decentralized P2P/
17:45:23 <dom> RRSAgent, draft minutes
17:45:23 <RRSAgent> I have made the request to generate https://www.w3.org/2022/01/18-webrtc-minutes.html dom
18:27:09 <Zakim> Zakim has left #webrtc