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