00:12:35 <RRSAgent> RRSAgent has joined #wicg 00:12:35 <RRSAgent> logging to https://www.w3.org/2019/09/19-wicg-irc 00:13:17 <Travis> .. joining the meeting in progress 00:13:37 <Travis> SubTopic: Support for certs not anchored to WEb PKI (Self-signed) 00:14:14 <Travis> .. 00:14:32 <Travis> SubTopic: provide a way to specify a subprotocol 00:14:53 <Travis> It's not trival to find a place to put this in the protocol. 00:15:42 <Travis> Thought: put in first string, but not block data. 00:15:51 <Travis> Could do this without losing RTT 00:17:03 <Travis> But don't want to add extra complexity 00:23:28 <Travis> Two other issues not covered: conjestion control and stream prioritization 00:24:13 <iclelland> iclelland has joined #wicg 00:24:32 <wonsuk> wonsuk has joined #wicg 00:24:54 <yoav> q? 00:25:18 <jbroman> Topic is now WebCodecs 00:25:26 <jbroman> Peter Thatcher: does anyone want an intro? 00:25:31 <Travis> Scribe: jbroman 00:25:32 <jbroman> (response is yes) 00:25:46 <yhirano_> yhirano_ has joined #wicg 00:26:01 <jbroman> low-level API for media encode/decode 00:26:08 <jbroman> based on transform streams 00:26:33 <jbroman> useful for live streaming, faster-than-realtime encoding, realtime comms, ... 00:27:04 <jbroman> VideoEncoder takes image data and makes a bitstream 00:27:23 <jbroman> typically gotten from a MediaStreamTrack via VideoTrackReader 00:27:43 <jbroman> not strictly part of web codecs but pulled in as a dependency 00:28:29 <jbroman> slide example of constructing audio/video decoders from some readable streams 00:28:40 <jbroman> and plugging that into a <video> element 00:29:08 <jbroman> slide example of using this to transcode media by piping between decoder and encoder 00:29:10 <Travis> q+ to ask about codec discovery if not covered in the presentation... 00:30:14 <jbroman> slide comparing to MediaRecoder: more low-level, ... 00:30:36 <jbroman> similar comparison to MSE 00:31:07 <jbroman> comparison to WebRTC: more low-level, not tied to network transport, can choose what kind of transport you want 00:31:17 <jbroman> buffering is done by the application, not browser 00:31:31 <jbroman> all of this can be done by wasm but this is faster and more power-efficient 00:31:44 <jbroman> access to hw encode/decode 00:32:14 <jbroman> track reader/writer would be useful for wasm codecs too, avoids having to use <canvas> 00:32:35 <yoav> q+ on images 00:32:43 <jbroman> proposal, explainer and webidl but no spec 00:32:46 <jbroman> impl starting soon in chromium 00:32:47 <jbroman> q? 00:32:52 <jbroman> ack Travis 00:32:52 <Zakim> Travis, you wanted to ask about codec discovery if not covered in the presentation... 00:33:10 <jbroman> Travis: can you enumerate supported codecs? 00:33:20 <jbroman> Peter Thatcher: that's the first issue under capabilities 00:33:36 <jbroman> we want to use media capabilities; don't want to duplicate it 00:33:45 <jbroman> there are specific needs to add to capabilities 00:33:59 <jbroman> e.g. low latency vs b-frames 00:34:12 <jbroman> a lot of people want to explicitly choose hw or sw encoder, since some hw encoders are bonkers 00:34:29 <jbroman> for low-level things like svc, there is no support inside MediaRecorder or MSE but we want it 00:34:45 <jbroman> concerned about expanding the fingerprinting surface by telling more to the app 00:34:59 <jbroman> Travis: have you approached them? 00:35:08 <jbroman> Peter Thatcher: yes, and they're engaging 00:35:16 <jbroman> Travis: agree with general sentiment 00:35:17 <jbroman> q? 00:35:19 <jbroman> ack yoav 00:35:19 <Zakim> yoav, you wanted to comment on images 00:35:34 <jbroman> yoav: you mentioned image encode/decode; I suspect this will be an ask 00:35:43 <jbroman> what is the current status? 00:35:57 <jbroman> Peter Thatcher: there was a lengthy discussion; even made a pr 00:36:15 <jbroman> the more we dug into the use cases people wanted, it became unclear whether it was worth it vs wasm or having a one-frame video 00:36:20 <jbroman> currently consider it out of scope 00:36:38 <jbroman> it occurred after a <img>/<video> discussion yesterday that if we could take decoder output and put it in an <img> that would be good 00:36:51 <dharani> dharani has joined #wicg 00:37:00 <jbroman> yoav: I think img/video discussion is different because if app developers are involved, they can just have a muted <video> in all cases except background-image 00:37:08 <jbroman> in background-image case this solution wouldn't help anyway 00:37:25 <jbroman> I don't think that covers the use cases people have when they want to put videos into <img> elements 00:37:36 <jbroman> you're probably correct that people can do things with one-frame videos 00:37:47 <jbroman> at least in image formats today 00:37:58 <jbroman> there might be an image format in the future that is not 100% identical to video format even if inspired 00:38:05 <jbroman> why does it matter if it's one-frame video or image format? 00:38:13 <jbroman> Peter Thatcher: one interesting case is gifs 00:38:22 <jbroman> somebody wanted to encode (animated) gifs 00:38:26 <jbroman> yoav: as an encoding output? 00:38:28 <jbroman> Peter Thatcher: yes 00:38:31 <jbroman> would we call that a video? 00:38:38 <jbroman> there is no containerization right now 00:38:44 <jbroman> is there such a thing as a containerized gif? 00:38:59 <jbroman> images always have containerization; for video it's nice to have bistream w/o container 00:39:03 <jbroman> yoav: ok 00:39:05 <jbroman> q? 00:39:13 <jbroman> Steve Anton: in summary it seemed like scope creep 00:39:21 <jbroman> can do image encode/decode with current apis 00:39:35 <jbroman> yoav: would be interested to hear the use case for gif; do we really want more animated gifs? 00:39:43 <jbroman> ???: lots of internet traffic is memes 00:40:00 <jbroman> Travis: drill into answer about existing way to do image encode 00:40:06 <jbroman> Steve Anton: you can write it to a canvas 00:40:36 <jbroman> Travis: want to be able to bring image payload down from server and decode it later, and recapture the memory later if it goes out of view 00:40:42 <jbroman> want to manage that at a fine-grained level 00:40:53 <jbroman> rbyers: didn't we recently ship something like that (jsbell?) 00:41:04 <iclelland> iclelland has joined #wicg 00:41:33 <jbroman> rbyers: HTMLImageElement.decode; forces eager decode 00:41:41 <jbroman> Travis: can you provide user-defined codec? 00:41:47 <jbroman> Peter Thatcher: yes, injectable codecs 00:42:06 <jbroman> can use simd extensions to wasm etc, but need to get it into/out efficiently 00:42:12 <jbroman> that's where track reader/writer comes into play 00:42:18 <jbroman> we discussed this at a breakout session 00:42:26 <jbroman> want to allow injectable codecs in WebRTC API 00:42:31 <jbroman> Travis: can this be done off-thread? 00:42:38 <jbroman> Peter Thatcher: should be possible, in a worklet 00:42:55 <jbroman> Steve Anton: Web Codecs is more about exposing the platform codecs 00:43:11 <jbroman> though there is interest in allowing injectable codecs in MSE, etc 00:43:23 <jbroman> it is more relevant to those APIS than to Web Codecs 00:43:55 <jbroman> Amit: don't you want it to work the same way as web codecs? 00:44:12 <jbroman> Peter Thatcher: similar API shape, could use Web Codecs or custom codecs 00:44:22 <jbroman> Steve Anton: could imagine constructing a codec on a worker, using it on main thread, etc 00:44:49 <jbroman> s/Amit/Amit Hilbuch/ 00:45:04 <jbroman> Peter Thatcher: Next issue: some codecs require extra out-of-band data, like H.264 SPS/PPS 00:45:27 <jbroman> ???: isn't this usually embedded in the container? 00:45:40 <jbroman> Steve Anton: could be, yes 00:45:57 <jbroman> Peter Thatcher: usually extracted from container format and then passed to decoder 00:46:15 <jbroman> (example shows it passed as options to the VideoDecoder ctor 00:46:16 <jbroman> ) 00:46:40 <jbroman> Steve Anton: this is data necessary for decoder itself 00:46:54 <jbroman> Amit Hilbuch: should these be specified in IDL or be freeform? 00:47:05 <jbroman> Peter Thatcher: in WebRTC we have key-value pairs; would probably mimic that 00:47:11 <jbroman> Steve Anton: settings are codec-specific 00:47:31 <jbroman> Amit Hilbuch: agree, wouldn't want to bake specific codec parameters into web standard 00:48:08 <jbroman> Steve Anton: is it fine to specify statically at decoder construction, or would they need to change later on, e.g. per-chunk 00:48:31 <jbroman> Amit Hilbuch: how are these different from ??? 00:48:41 <jbroman> Steve Anton: distinction between things needed to understand bitstream vs encoder hints 00:49:28 <jbroman> Steve Anton: are there parameters needed to understand the bitstream that are not known when the decoder is constructed? 00:49:33 <jbroman> need to consult codec experts 00:49:41 <jbroman> Peter Thatcher: next issue: decoding b-frames 00:49:55 <jbroman> in video codecs there are dependencies between frames 00:50:00 <jbroman> b-frames depend on future frames 00:50:03 <jbroman> need to decode out of order 00:50:12 <jbroman> how do we support this in the decoder api? 00:50:20 <jbroman> yoav: buffering? 00:50:45 <jbroman> Peter Thatcher: require JS to handle it by getting it in decode order; JS can reorder after 00:50:55 <jbroman> but hardware decoders reorder internally 00:51:07 <jbroman> Steve Anton: feels like most decoders could efficiently reorder for you 00:51:11 <jbroman> even sw decoders 00:51:23 <jbroman> Peter Thatcher: do we make the API such that decoders can do it more efifciently? 00:51:32 <jbroman> so far we've added a timestamp to the info going into the decoder 00:51:37 <jbroman> so that it can do the buffering 00:51:41 <jbroman> but if you opt into low latency 00:51:46 <jbroman> then this timestamp would be unimportant 00:51:58 <jbroman> Steve Anton: requiring timestamps doesn't seem too onerous if you don't need them 00:52:01 <jbroman> can just increment by 1 00:52:08 <jbroman> Travis: seems like surrogate pairs 00:52:12 <jbroman> where it's useless to get half of it 00:52:21 <jbroman> almost always just want full character in e.g. HTML parser 00:52:40 <jbroman> is the b-frame an implementation detail, or does it need to be exposed? 00:52:49 <jbroman> Steve Anton: wouldn't get partial images; just get frames out of order 00:52:57 <jbroman> would get keyframe and then partial frames that come before 00:53:14 <jbroman> would the decoder expose the keyframe or wait until after the delta frames have been emitted 00:54:09 <jbroman> yoav: I would ask developers (a) is there an actual use case to get the frames out of order? (b) what is their preference? do they want the API to magically handle that or not? 00:54:17 <jbroman> Peter Thatcher: that's a good idea to ask on discourse 00:54:21 <jbroman> pretty sure I know what they will say 00:54:31 <jbroman> "do you want to do extra work or do you want us to?" 00:54:41 <jbroman> yoav: would it be more efficient in some way if it's done in js? doesn't seem so 00:54:55 <jbroman> ???: which timestamp? 00:55:01 <jbroman> Peter Thatcher: presentation timestamp 00:55:27 <jbroman> Peter Thatcher: next issue: complex coding modes 00:55:32 <jbroman> e.g. SVC 00:55:37 <jbroman> SVC is Scalable Video Coding 00:55:44 <jbroman> progressive images, but for video 00:55:49 <jbroman> different "layers" that depend on each other 00:55:59 <jbroman> useful in real-time communication, e.g. video conferencing 00:56:13 <jbroman> surprised it hasn't been popular in livestreaming 00:56:19 <jbroman> Steve Anton: also useful in offline playback 00:56:30 <jbroman> Peter Thatcher: with only a portion of the bitstream, can decode a lower-quality version 00:56:40 <jbroman> yoav: how does that work wrt video length? 00:56:45 <jbroman> is it "for every x frames"? 00:57:23 <jbroman> (overlapped discussion about how this is implemented, and complicated diagrams in a spec) 00:57:36 <jbroman> Peter Thatcher: simple case has bigger frames dependent on smaller frames 00:57:40 <jbroman> yoav: okay, so each frame is progressive 00:57:47 <jbroman> Peter Thatcher: but it can get more complicated 00:57:51 <tantek> tantek has joined #wicg 00:57:54 <jbroman> Steve Anton: SVC is similar to JPEG progressive decode 00:58:12 <jbroman> Peter Thatcher: from encoder API standpoint, put in 1 frame and get out n frames for same timestamp 00:58:15 <tantek> RRSAgent, make logs public 00:58:31 <jbroman> dependencies between them 00:58:36 <jbroman> similar to time dependencies in normal delta frames 00:58:42 <jbroman> but this impacts the api 00:58:51 <jbroman> when decoding, get different frames for same timestamp 00:59:03 <jbroman> maybe you get a higher-quality frame after having rendered the lower-quality frame 00:59:16 <jbroman> 1 frame in - 1 frame out no longer applies 00:59:21 <jbroman> have tried to integrate into the api 00:59:29 <jbroman> but expressing how you want it set up can be complex 00:59:39 <jbroman> expressing what is possible through media capabilities is also complex 00:59:47 <jbroman> yoav: is there a preference 01:00:00 <jbroman> e.g. I'm a low-power device, only want partial layers? 01:00:11 <jbroman> but client and server could have communicated that 01:00:27 <jbroman> Peter Thatcher: in real-time comms, client asks for higher res version that is available according to network conditions 01:00:36 <jbroman> yoav: device could say max quality it can handle 01:00:45 <jbroman> Amit: that's in signaling 01:00:54 <jbroman> yoav: maybe in media capabilities you want to know what's possible 01:01:05 <jbroman> Peter Thatcher: might have a limit in how many layers you can do 01:01:10 <jbroman> not just for video 01:01:15 <jbroman> in audio, opus fec 01:01:28 <jbroman> particular packet can contain current time's high quality audio and previuos time's low quality audio 01:01:36 <jbroman> so if you miss a packet you can fill in with the low quality version 01:01:54 <jbroman> so from an opus bitstream you can decode either high or low quality data 01:02:03 <jbroman> Steve Anton: might be able to figure it out automatically 01:02:07 <jbroman> based on gaps in timestamps 01:02:11 <jbroman> Peter Thatcher: good point 01:02:14 <jbroman> could treat it like SVC 01:02:28 <jbroman> if you get the earlier one first and high quality one later, get a second audio frame at the same time 01:02:37 <jbroman> Steve Anton: at encode side, just need a way to turn it on 01:02:40 <jbroman> Peter Thatcher: agreed that it's easy 01:02:46 <jbroman> decode is what's interesting 01:03:11 <jbroman> Steve Anton: with SVC, multiple layers make up one frame 01:03:17 <jbroman> if you expect to get all the layers you want to wait 01:03:37 <jbroman> might need a way to flush what's currently available 01:03:56 <jbroman> yoav: how can we facilitate this in the futuree? 01:04:05 <jbroman> Peter Thatcher: might not want to implement all of this now 01:04:13 <jbroman> but don't want to paint ourselves into a corner 01:04:18 <jbroman> Steve Anton: can't assume frame in, frame out 01:04:30 <jbroman> yoav: at the same time, a future application using those coding modes will be aware of it 01:04:38 <jbroman> they will know that multiple frames can come out, etc 01:05:00 <jbroman> Peter Thatcher: skipping Timestamps and time domains because Paul isn't here 01:05:42 <jbroman> short version: when we go from readable streams to tracks, for audio want to give it to OS as needed; for video to keep it smooth you want to say when a video frame is presented 01:06:01 <jbroman> if you just take frames from decoder as fast as they come out, it might not be smooth 01:06:12 <jbroman> ???: might need to drop frames to keep smooth? 01:06:31 <jbroman> Peter Thatcher: how do you decide which frame goes out on a particular vsync? 01:06:48 <jbroman> if we put JS in complete control, prone to JS pauses 01:06:59 <jbroman> Steve Anton: concern already exists e.g. with WebGL 01:07:05 <jbroman> so might not be intractable 01:07:12 <jbroman> Peter Thatcher: might not be clear until we try to implement 01:07:15 <jbroman> Paul has better ideas 01:07:41 <jbroman> Todd: expected to be done off render thread? 01:07:57 <jbroman> Peter Thatcher: yes; still may want to control what frame goes out on what vsync 01:08:03 <jbroman> Todd: sounds like it might be more efficient 01:08:19 <jbroman> Peter Thatcher: if latency isn't as important, buffering to provide smoothness might be more important 01:08:23 <jbroman> vs real-time use cases 01:09:15 <Travis> Thanks jbroman ! 01:09:20 <jbroman> Topic: information pipeline between WICG and web developers 01:09:30 <jbroman> yoav: don't know if this is interesting to non-chairs 01:09:41 <jbroman> Todd: what is the core of the question? 01:09:56 <jbroman> yoav: I think discourse today is mostly used as a "bring us your proposal" forum 01:10:01 <jbroman> not the most effective way to get stuff done 01:10:27 <jbroman> would be interesting to use it more, or use another means more, to get use cases from developers 01:10:31 <jbroman> and then iterate over API shape questions 01:10:46 <jbroman> Todd: when you say use cases, you mean problems that are difficult or impossible to solve? 01:10:51 <jbroman> and exactly what are you trying to do? 01:10:58 <jbroman> rather than "I dreamed of this API shape" 01:11:10 <jbroman> yoav: is that worthwhile to discuss in this forum? 01:13:45 <jbroman> cwilso: is discourse the right entry point to wicg, or would something else make more sense? I drew the parallel in the AC meeting; there is 1:1 overlap between ???. The way we start things up is similar to WICG. We ask to see evidence that >1 person cares about this problem to give it legitimacy. Immersive Web Group has specific "proposals" repo. File an issue; everyone follows this repo. Sometimes we still have competing repos about interesting 01:13:45 <jbroman> ideas. That's how we do it; we barely use our mailing list. Would that be easier than using discourse? 01:14:16 <jbroman> I don't go to discourse often 01:14:20 <jbroman> Travis: but you do go to github often 01:14:35 <jbroman> cwilso: I do, but don't necessarily dig into the right repo every day 01:14:46 <jbroman> Todd: how to keep web developers engaged, understand what are the issues? 01:15:02 <jbroman> cwilso: process for starting in WICG is intended to be easy but still have a minimum bar 01:15:12 <jbroman> we do ask that every incubation proposal has >1 organization 01:15:21 <jbroman> if 15 Google employees say it's a good idea, that's not good enough 01:15:29 <jbroman> but 1 web dev + 1 MS employee, that's good enough 01:15:38 <jbroman> some measure of cross-industry interest 01:15:44 <jbroman> are we using the right mechanism for that? 01:15:50 <Guest19> Guest19 has joined #wicg 01:16:00 <jbroman> yoav: there's the question of engagement, and beyond that, once you've got people engaged, what do you actually want from them? 01:16:23 <jbroman> I think that I traditionally try to get web devs more involved in standards, but it may have been a mistake in the sense that people don't necessarily have time to do that on top of their job 01:16:50 <jbroman> at the same time, an engagement that says "here is a problem space we're looking at; give us your use cases and pain points" 01:17:04 <jbroman> and they just have to write 100 words and leave and don't have to follow up as a long-term commitment 01:17:13 <jbroman> that is something that developers are actually likely to be interested in doing 01:17:17 <jbroman> if we make it easy/welcoming enough 01:17:35 <jbroman> Travis: I wonder how much a developer feels like they get to be a part of it if they just pop in, make a suggestion, and never come up 01:17:38 <jbroman> what's missing is the follow-up 01:17:44 <jbroman> that we turned your random idea into something complete 01:17:48 <jbroman> wdyt? does it still work? 01:17:59 <jbroman> How can we make sure that's working unless we keep them engaged? 01:18:01 <jbroman> yoav: discourse, github 01:18:24 <jbroman> once we have some API shape, we can ask them if it would address their use case or not 01:18:35 <jbroman> we can try to have long-term engagement in terms of revalidating use cases, API shape, etc over time 01:18:37 <jbroman> until shipped 01:18:41 <jbroman> but doesn't require them to do a ton of work 01:18:55 <jbroman> Travis: could be done through discourse or github, orthogonal to the question? 01:18:59 <jbroman> yoav: not a tooling question 01:19:14 <jbroman> do we want to take that approach? can pick a tool after that 01:19:31 <jbroman> chairs, does that make sense as a browser developer? 01:19:46 <jbroman> Steve Anton: web developers have a hard time getting excited about proposals 01:19:50 <jbroman> they seem so far off 01:19:52 <jbroman> first step is use cases 01:19:58 <jbroman> devs happy to talk about use cases 01:20:19 <jbroman> there's a gap where it's hard to get them involved in middle stages 01:20:21 <jbroman> until origin trial 01:20:43 <jbroman> cwilso: early part of "Web dev has a use case" is outside of this 01:20:52 <jbroman> more like "web we want" effort 01:21:08 <jbroman> let's turn early use cases into actionable problem statements for further incubation 01:21:12 <jbroman> so many people come up with problems 01:21:21 <jbroman> but thinking about how to solve in a broader space is hard sometimes 01:21:42 <jbroman> I'm more concerned about having an active set of people, how do we get more people engaged in solution efforts? 01:21:51 <jbroman> yoav: define "engage in solution efforts" 01:22:00 <jbroman> cwilso: iterating on problem statements, solutions in incubation process 01:22:28 <jbroman> a number of incubations had people saying it was interesting, turns into one person creating, proposing, implementing, experimenting w/o a lot of engagement 01:22:29 <jbroman> that's tough 01:22:39 <jbroman> not saying that's a totally broken pattern but shouldn't be the usual pattern 01:22:55 <jbroman> Todd: if there are 5 people on discourse saying it's a good idea and one person begins work, how do all 5 people contribute? 01:23:03 <jbroman> cwilso: even continually engaging after that 01:23:12 <jbroman> one downside of discourse is that it's for initial stages only 01:23:18 <jbroman> once there's a repo, it's disconnected from discourse 01:23:25 <jbroman> conversation moves into a different tool altogether 01:23:29 <jbroman> that seems odd 01:23:44 <jbroman> Peter Thatcher: with Web Transport, had some people interested; wanted to have community discussion 01:23:50 <jbroman> wasn't sure whether to use discourse, github, mailing list, ? 01:23:56 <jbroman> lack of a way to keep interested people in the loop 01:24:07 <jbroman> Todd: does an individual effort have a single discourse thread? 01:24:16 <jbroman> cwilso: usually one, but once repo created there's no conversation there 01:24:29 <jbroman> Todd: a bot to update discourse thread with # issues created etc? 01:24:35 <jbroman> yoav: there are also labels 01:24:53 <jbroman> theoretically you could have multiple threads and have them labelled 01:25:02 <jbroman> Todd: do we think the discourse thread don't go to the github 01:25:06 <jbroman> or do they not know? not have time? 01:25:08 <jbroman> do we know why/ 01:25:12 <jbroman> cwilso: we don't truly know why 01:25:25 <jbroman> part of it is that it's a barrier that we need to see engagement to create the repo 01:25:32 <jbroman> engagement beyond that is a long-term interest thing 01:25:38 <jbroman> human nature to have limited time/effort to expend 01:25:57 <jbroman> superstar is co-chair Marco (sp?) who comments on everything which is great 01:26:15 <jbroman> suspect if we used GitHub as that comm tool it might be easier to get interest from other people 01:26:25 <jbroman> we could manage tagging/labelling things in the proposals repo 01:26:33 <jbroman> so people could follow e.g. styling or networking proposals 01:26:48 <jbroman> Todd: replacing disocurse with github? 01:26:50 <jbroman> cwilso: yeah 01:26:55 <jbroman> s/disocurse/discourse/ 01:27:34 <jbroman> Peter Thatcher: when people were interested in Web Transport/Codecs, had to tell people to come to discourse page and people weren't familiar 01:27:50 <jbroman> maybe GitHub would be better 01:28:04 <jbroman> yoav: one way to resolve question would be to ask it 01:28:09 <jbroman> do a survey 01:28:20 <jbroman> provide multiple engagement mechanisms and ask that they would prefer 01:28:25 <jbroman> discourse vs github vs ??? with examples 01:28:52 <jbroman> Peter Thatcher: have you talked to foms (sp?); they have engagement from web devs about media stuff 01:29:04 <jbroman> whatever they're doing seems to do a good job 01:29:23 <jbroman> Todd: web performance wg has attended velocity conference (now renamed) 01:29:26 <cwilso> s/foms/FOMS: http://www.foms-workshop.org/foms2019SF/ 01:29:40 <jbroman> that did get some engagement 01:29:52 <jbroman> yoav: view source next week would get a good place to collect anecdata 01:29:56 <jbroman> cwilso: we should wrap up 01:30:06 <Travis> RRSAgent: make minutes 01:30:06 <RRSAgent> I have made the request to generate https://www.w3.org/2019/09/19-wicg-minutes.html Travis 01:30:17 <Travis> thanks Zakim 01:31:38 <iclelland> iclelland has joined #wicg 01:49:11 <iclelland> iclelland has joined #wicg 02:02:43 <iclelland> iclelland has joined #wicg 02:05:15 <aboxhall_> aboxhall_ has joined #wicg 02:06:30 <ericc> ericc has joined #wicg 02:23:47 <jihye> jihye has joined #wicg 02:51:12 <Zakim> Zakim has left #wicg 03:02:48 <ericc> ericc has joined #wicg 03:15:46 <iclelland> iclelland has joined #wicg 03:49:32 <iclelland> iclelland has joined #wicg 03:52:00 <iclelland> iclelland has joined #wicg 04:02:16 <iclelland> iclelland has joined #wicg 04:13:53 <ericc> ericc has joined #wicg 04:34:59 <ericc> ericc has joined #wicg 05:34:24 <Guest19> Guest19 has joined #wicg 05:45:43 <onix> onix has joined #wicg 05:48:55 <tiger> tiger has joined #wicg 06:06:03 <iclellan1> iclellan1 has joined #wicg 06:07:04 <bkardell_> bkardell_ has joined #wicg 06:28:19 <iclelland> iclelland has joined #wicg 06:30:22 <tantek> tantek has joined #wicg 06:37:18 <ericc> ericc has joined #wicg 07:53:26 <iclelland> iclelland has joined #wicg 07:57:43 <iclellan1> iclellan1 has joined #wicg 08:21:47 <tantek_> tantek_ has joined #wicg 08:28:34 <iclelland> iclelland has joined #wicg 09:29:46 <Rossen> Rossen has joined #wicg 09:31:17 <leaverou> leaverou has joined #wicg 10:57:02 <Guest19> Guest19 has joined #wicg 12:28:13 <iclelland> iclelland has joined #wicg 13:40:57 <iclelland> iclelland has joined #wicg 14:33:02 <iclelland> iclelland has joined #wicg