| 02:43 | <Domenic> | Sigyn is useless... |
| 02:44 | <devsnek> | Domenic: you need to op it lol |
| 02:45 | <Domenic> | Pretty sure I did |
| 02:48 | <devsnek> | its just listed as a member when i check |
| 02:48 | <Domenic> | Yeah but it should be able to op itself like I do with ChanServ |
| 02:49 | <Domenic> | Well, I manually made it op, let's see what happens |
| 02:49 | <Domenic> | It would be pretty sad if we could have stopped this spam at any time but failed |
| 03:23 | <Domenic> | So Sigyn is half-useless |
| 05:50 | <zewt> | jumping at the opportunity to employ an IRC ad service that spams a message to the same channel 20 times |
| 05:50 | <zewt> | that is an indication of a quality spammer |
| 12:46 | <jgraham> | So is there some solution for this channel being 100% spam over the last 12 hours? |
| 12:48 | <jgraham> | Or has everyone given up on it anyway? |
| 12:58 | <MikeSmith> | jgraham: not given up but some mitigation has been attempted using https://github.com/freenode/Sigyn but clearly it’s not worked very well |
| 12:59 | <MikeSmith> | and the messages aren’t really spam; they’re instead some kind of trolling attack against the freenode admins |
| 13:01 | <MikeSmith> | ...and maybe sent using some kind botnet such that it can’t be prevented through simple IP-range blocking or whatever |
| 13:12 | <wanderview> | another channel I'm in dealt with it by blocking anyone from talking unless the person is on a "voiced" list |
| 13:18 | <jgraham> | MikeSmith: I kind of meant the channel in general rather than the spam in particular; historically it's fairly unusual for things to be this quiet for this long |
| 13:18 | <jgraham> | MikeSmith: But thanks for the update |
| 13:50 | <annevk> | I suspect vacation/backlog as reasons for quietness, but have not seen stats |
| 13:52 | <jgraham> | Could be. I started to wonder if everyone had moved to some backchannel on slack or something |
| 13:58 | <annevk> | I’m not aware of any, FWIW |
| 13:58 | <jgraham> | Maybe everyone just ran out of things to say :) |
| 14:16 | <wanderview> | maybe everyone is saving their best material for tpac |
| 15:29 | <Domenic> | annevk: https://github.com/whatwg/html/pull/3811 LGTY? |
| 15:40 | <ato> | Ms2ger: Thanks for setting +r. |
| 15:41 | <Ms2ger> | Np |
| 15:51 | <annevk> | Domenic: reviewed |
| 15:52 | <annevk> | Domenic: it's gonna take at least another week before I worked through my backlog; rather busy summer |
| 15:52 | <annevk> | have worked* |
| 15:55 | <Domenic> | annevk: sure no problem. Feel free to use "LGTM with nits" approval to reduce round trips :) |
| 16:03 | <domfarolino> | Domenic: If a window's referrer policy was set to "no-referrer", would top-level module worker requests from this window use that policy, and thus omit a referrer, or use a default policy, and send the window's URL? |
| 16:04 | <domfarolino> | https://github.com/web-platform-tests/wpt/blob/master/workers/modules/dedicated-worker-import-referrer.html#L93 has me a little bit confused as I compare it with the spec, but I definitely could be reading something wrong |
| 16:07 | <domfarolino> | Spec seems to eventually defer to “outside settings” referrer, but I think that conflicts with the test case. |
| 16:08 | <domfarolino> | s/referrer/referrer policy, in my latest msg |
| 16:31 | <Domenic> | domfarolino: hmm yeah those tests seem wrong |
| 16:31 | <Domenic> | The ones *inside* should use default referrer policy I think |
| 16:31 | <Domenic> | Although fixing that would be nice |
| 16:31 | <Domenic> | That's a larger problem space: https://github.com/w3c/webappsec-referrer-policy/issues/111 |
| 16:57 | <domfarolino> | Domenic: and those *inner* requests that use the default referrer policy, will eventually resolve to using that of fetch client settings object, (which’ll be “no-referrer” in my example) right? |
| 16:57 | <Domenic> | Hmm... |
| 16:57 | <domfarolino> | Also what you propose in that issue seems reasonable. |
| 16:58 | <Domenic> | Yeah just a decent amount of work |
| 16:58 | <Domenic> | I guess you're right they would resolve to "no-referrer" |
| 16:58 | <domfarolino> | The reason I’m wondering if it’ll end up being “no-referrer” in that example is because we still use fetch client settings (outer setitjnfs) as the inner request’s client I think, right? |
| 16:58 | <Domenic> | So the tests further down are probably wrong too? |
| 16:58 | <domfarolino> | Ah ok |
| 16:58 | <domfarolino> | Yeah I think so |
| 16:58 | <Domenic> | Worth checking with the test author (probably nhiroki) to make sure I'm not missing anything |
| 16:59 | <domfarolino> | Will do. He’s reviewing some refactoring I’m doing in that area so will run by him. |
| 17:04 | <domfarolino> | I originally though we used “inner settings” as inner request clients but that does not seem to be the case. |
| 19:44 | <annevk> | So now Token Binding is mostly gone again… |
| 20:26 | <jyasskin> | https://fetch.spec.whatwg.org/#concept-construct-readablestream creates a non-byte ReadableStream, even though Fetch only enqueues Uint8Arrays. Is that optimizable internally, or should it change? |
| 20:28 | <Domenic> | Both, I think :). |
| 21:32 | <jyasskin> | Domenic: This might be https://github.com/whatwg/fetch/issues/267. |