| 01:00 | <styfle> | Is it too late to change this for tomorrow? https://github.com/tc39/agendas/pull/1932 |
| 01:08 | <Michael Ficarra> | it's not too late, but people may block advancement to 2 based on late notice |
| 01:14 | <Michael Ficarra> | at this point, there's not much point in updating the agenda though, it's virtually the same as just springing it on people during your agenda item |
| 16:53 | <ryzokuken> | @room starting in 7 mins! |
| 17:04 | <nicolo-ribaudo> | Wow this note taker is excellent |
| 17:07 | <nicolo-ribaudo> | And I fix a mistake they make, they see it, and they write it correctly the next time |
| 17:08 | <nicolo-ribaudo> | What, Ujjwal said "Shane" and the person wrote "SFC"??? |
| 17:09 | <Aki> | !! amazing |
| 17:10 | <Jesse> | I've also seen that before; I wonder if it's in part due to being early in the day |
| 17:11 | <bakkot> | note taker was doing it yesterday too |
| 17:11 | <bakkot> | I was very impressed |
| 17:12 | <Zb Tenerowicz (ZTZ/naugtur)> | this week's notetaker can even recognize speakers by voice (saw that yesterday) |
| 17:15 | <nicolo-ribaudo> | They are just adding attributions by themselves, it's impressive I good they are |
| 17:15 | <nicolo-ribaudo> | I'm basically just reading the notes instead of fixing things |
| 17:16 | <Chris de Almeida> | this is great feedback, and also feedback we can provide to the service, which helps them as well |
| 17:17 | <Chris de Almeida> | and it's always nice to hear about good things about the transcription since (understandably) usually if we get any feedback, it's negative |
| 17:17 | <ljharb> | (there's still hard wraps in the middle of a paragraph tho, and still double spaces after punctuation, which are fixable later) otherwise tho it is quite excellent |
| 17:17 | <Chris de Almeida> | 🤫 shhhh.... no tears now. only dreams |
| 17:20 | <Chris de Almeida> | it appears that someone copy/pasted the day 2 attendee list into day 3. please don't do that |
| 17:23 | <Chris de Almeida> | I have removed from the day 3 list those who are not in attendance |
| 17:24 | <snek> | not anything against this proposal in particular but i feel like conditional advancement is really becoming popular lately |
| 17:25 | <snek> | not sure if its a good or bad thing. good to get more velocity i guess. |
| 17:26 | <ljharb> | it's reduced bureacracy and plenary time |
| 17:27 | <ryzokuken> | basically it saves the plenary 5-10 mins (of us coming back in two months) and saves us anywhere from two months to a few weeks. |
| 17:29 | <ryzokuken> | honestly it doesn't change much practically but now we can pretty much start writing tests right away with the understanding that any remaining questions would most likely be editorial in nature. If there was indeed a high chance of changes it'd have been irresponsible to ask for conditional advancement, so this is basically what helps me decide |
| 17:31 | <nicolo-ribaudo> | kriskowal: You'll need to edit the notes because the transcriber is too good now so all of the pronounciations have been replaced by ZTZ |
| 17:33 | <bakkot> | so, how do we feel about this being based on eval |
| 17:34 | <bakkot> | I would feel more positively about a proposal in this vein based on module expressions |
| 17:34 | <nicolo-ribaudo> | Would it be with a method on the global "run this module expression"? |
| 17:34 | <bakkot> | yeah basically |
| 17:34 | <Mathieu Hofman> | I don't think the proposal is based on eval, it simply deals with the fact evaluators exists in the language |
| 17:35 | <bakkot> | the proposal literally only provides new mechanisms if you are using eval |
| 17:35 | <nicolo-ribaudo> | I vaguely remember talking with you about not having more paths to evaluation, a method to evaluate a module might be one |
| 17:35 | <bakkot> | or rather, module expressions are syntax, but it would be "run this module source" and then have module expressions which evaluate to module sources |
| 17:35 | <Mathieu Hofman> | if you can evaluate a module expression in a new Global, you need to ensure the evaluators in available in there don't let you evaluate in the original global |
| 17:36 | <bakkot> | sure, I am open to considering which ancillary features would be necessary to make my suggestion work |
| 17:36 | <bakkot> | but the proposal as is is only about evaluators |
| 17:37 | <Mathieu Hofman> | Having a mechanism to trigger evaluation in a new Global being based on ModuleSource without requiring an eval call does make sense. |
| 17:38 | <Mathieu Hofman> | The proposal is about adding a level of indirection between Realm and the Evaluation Context |
| 17:38 | <Mathieu Hofman> | evaluators are the visible side effect of that |
| 17:38 | <Ashley Claymore> | import(module { ... }) |
| 17:39 | <nicolo-ribaudo> | This doesn't work on a different global, because import is not a property of it |
| 17:40 | <nicolo-ribaudo> | From this past slide it looks like indeed there is a need for evaluting sources, since it's exactly what it did with eval("s => import(s)") |
| 17:40 | <snek> | wouldn't we need a watchdog api for this to handle untrusted input |
| 17:40 | <Mathieu Hofman> | whatchdog ? |
| 17:40 | <snek> | like "run code with timeout" |
| 17:40 | <bakkot> | also the proposal as is still lets you do [].constructor.constructor('whatever') so... I just don't understand that argument at all |
| 17:40 | <snek> | otherwise you can do while (true) {} |
| 17:42 | <Mathieu Hofman> | Sure, and? you're running code in the same agent. ShadowRealm does not have any availability guarantee. This is not pretending to add any such guarantee either. |
| 17:42 | <snek> | well i'm just replying to "run untrusted code" |
| 17:42 | <snek> | as a general concept |
| 17:42 | <snek> | which seems like a dangerous goal if you don't solve dos somehow |
| 17:42 | <Mathieu Hofman> | As was mentioned first, this proposal is the necessary minimum for sandboxing, it is not sufficient, and user land has other work to do if sandboxing is the goal |
| 17:43 | <bakkot> | ok but then why can't that work be like "replace eval and Function" |
| 17:44 | <Mathieu Hofman> | Because there is no way to create in userland an eval and Function implementation that work with that new Global |
| 17:44 | <bakkot> | right but why do you want that |
| 17:44 | <bakkot> | why are we concerned about providing new facilities for using eval |
| 17:44 | <bakkot> | just don't use eval |
| 17:44 | <Mathieu Hofman> | because those are part of the language? Why do you want to remove them? they exist in a global today |
| 17:45 | <bakkot> | in practice they do not exist because almost all frontend code is or ought to be written on the assumption that it will be running in an environment in which CSP forbids use of eval |
| 17:45 | <nicolo-ribaudo> | bakkot is this specifically about eval, or in general about the concept of "running some code with a different global context"? like the module expression solution you suggested earlier |
| 17:45 | <bakkot> | eval (and friends) |
| 17:45 | <bakkot> | string-based evaluation |
| 17:45 | <Mathieu Hofman> | Ok and CSP would keep applying here, so I don't understand the concern |
| 17:45 | <nicolo-ribaudo> | It seems to me like eval here is not the goal but just the tool identified to reach it |
| 17:46 | <bakkot> | running code in a different global context is a reasonable idea as long as that code doesn't come from strings |
| 17:46 | <bakkot> | the concern is, why is this proposal going to a bunch of effort to provide new ways to use eval |
| 17:46 | <bakkot> | I do not want to provide new ways to use eval |
| 17:46 | <nicolo-ribaudo> | heh, to implement a module system at some point you need to read a file and turn that into runnable code |
| 17:46 | <bakkot> | the host can do that for you though! |
| 17:47 | <Jesse> | chmod +x file boom |
| 17:47 | <Ashley Claymore> | import.source |
| 17:47 | <snek> | >the host will save you from getting code from strings >look inside the host >getting code from strings /s |
| 17:48 | <Ashley Claymore> | I bet it's using memory addresses too. Wild |
| 17:48 | <snek> | element won't let me format this as proper green text aaaaaaaaa |
| 17:48 | <bakkot> | |
| 17:49 | <snek> | so true |
| 17:57 | <nicolo-ribaudo> | bakkot Fyi many people working on modules agree with your point about the import hook, but it's a post-stage-1 thing |
| 18:03 | <nicolo-ribaudo> | Without eval you wouldn't be able to load existing CommonJS-based libraries, right? |
| 18:03 | <nicolo-ribaudo> | CommonJS depends on eval |
| 18:03 | <ljharb> | how does it depend on eval |
| 18:04 | <ljharb> | i mean in node it's an implementation detail |
| 18:04 | <nicolo-ribaudo> | How would you implement it without eval? |
| 18:04 | <ljharb> | and in browsers via bundlers it doesn't rely on eval |
| 18:05 | <nicolo-ribaudo> | I mean this whole proposal can be replaced with a build step, replacing all global references thatThing with myCustomGlobal.thatThing |
| 18:05 | <ljharb> | i don't consider "let the engine evaluate it outside of JS" eval, so you'd modify the source and give it to the engine |
| 18:05 | <ljharb> | "eval" in this context imo is eval and Function and setTimeout strings etc |
| 18:05 | <snek> | how do you give it to the engine without eval |
| 18:05 | <ljharb> | the engine isn't using javascript eval, so it's not eval :-) |
| 18:06 | <ljharb> | obviously it's turtles all the way down but that's not relevant |
| 18:06 | <snek> | so some new thing called ScriptSource or something |
| 18:06 | <snek> | instead of eval |
| 18:07 | <ljharb> | inside node it could be done in C++ or something, the point is that user JS code wouldn't be doing the string evaluation |
| 18:20 | <nicolo-ribaudo> | The fact that this shares all the globals, unlike Node.js's VM, doesn't really make it seem like a sandbox to me |
| 18:21 | <ljharb> | it's confusing to me that it shares a % of globals that's not zero and not 100 |
| 18:22 | <bakkot> | I mean the whole point of it is evaluating things in a way that they can't see some of your stuff |
| 18:22 | <bakkot> | that sounds like a sandbox to me |
| 18:23 | <nicolo-ribaudo> | But it doesn't hide your stuff by default, at all |
| 18:23 | <rekmarks> | IMO, people confuse Node's vm module for a sandbox because it's called "VM", which is something used for sandboxing. I don't see why a JavaScript developer would assume that "an API that creates a new global object" would function as a sandbox, nor do I think that its potential / off-label use as a building block for an actual sandbox makes this more likely. |
| 18:23 | <bakkot> | right but that is literally the whole point of it |
| 18:23 | <bakkot> | there is no reason to use this unless you care about being able to evaluate code in a way that it can't see some of your stuff |
| 18:26 | <nicolo-ribaudo> | Or to run some code that sees more stuff, like you have a file expecting a given global to be available (regeneratorRuntime? 👀) but you don't want to actually make that global globally available just because of one bad library |
| 18:27 | <bakkot> | sure, I guess |
| 18:27 | <snek> | creating new environments to run trusted code that expect a different runtime environment is a valid use case |
| 18:27 | <snek> | and doesn't require a sandbox |
| 18:27 | <snek> | i agree its a footgun though |
| 18:31 | <snek> | hm something i do wonder. agoric's security model currently requires actively analyzing every proposed change to the language to see whether it would break it. if we are adding this functionality to replace compartments/etc, are we increasing the surface area that requires this active approach? or reducing it? compared to stronger apis that actually guarantee isolation. |
| 18:31 | <nicolo-ribaudo> | Zb Tenerowicz (ZTZ/naugtur): kriskowal Would the champions be ok with the problem statement roughly as worded by Kevin? |
| 18:32 | <dminor> | Sorry to cut that off, I'm sure we'll find time to continue this plenary. I just want to make sure Steven gets his full time slot. |
| 18:33 | <bakkot> | I think of import hooks as being motivated completely independently of the "new global" thing, personally, so I am happy to hear they're different proposals |
| 18:38 | <Michael Ficarra> | oof is snek's TCQ entry PoO worthy? |
| 18:38 | <snek> | i wasn't really sure |
| 18:38 | <nicolo-ribaudo> | Michael Ficarra It's in the same class as the json modules proposal |
| 18:39 | <Michael Ficarra> | let's just make sure we address it before the rest of the queue |
| 18:41 | <bakkot> | eemeli: I also like type: "text" but I think it would have to be its own proposal, with its own motivation |
| 18:43 | <Michael Ficarra> | @eemeli you'd need an encoding |
| 18:43 | <snek> | i feel aesthetically displeased with gradually adding all this stuff to modules but we can't do it properly like include_bytes! in compiled languages so maybe it's ok to put it in modules... |
| 18:43 | <bakkot> | no it would just be utf8 |
| 18:43 | <bakkot> | everything on the web assumes utf8 |
| 18:44 | <Michael Ficarra> | WTF-8? |
| 18:44 | <bakkot> | well, something like that anyway |
| 18:44 | <bakkot> | like TextEncoder doesn't provide any other encodings, etc |
| 18:44 | <nicolo-ribaudo> | Just add a second attribute for encoding /s |
| 18:44 | <bakkot> | if you want something else you have to import bytes and do your own transcode |
| 18:44 | <eemeli> | Yeah, I only want utf-8 |
| 18:45 | <snek> | this is decoding not encoding. and TextDecoder does support more encodings |
| 18:45 | <bakkot> | ... huh, for some reason I thought it didn't |
| 18:45 | <bakkot> | I guess I was just thinking of Encoder |
| 18:45 | <snek> | TextEncoder only supports utf8 |
| 18:45 | <snek> | yeah |
| 18:46 | <snek> | happy to leave that can of worms to a separate proposal though :> |
| 18:51 | <nicolo-ribaudo> | Getting my point off the queue to not waste the timebox with process, but I think we are the right venue here. Unlike CSS modules, Uint8Arrays are something that we provide. And unlike WinterTC, this is very much also important (especially?) on non-web-like runtimes |
| 18:52 | <Michael Ficarra> | thanks for the great responses to my query, they have made me feel a lot better about this proposal |
| 18:52 | <nicolo-ribaudo> | What we would be doing, however, is only saying "if there is this import and it does not fail, it must result in a Uint8Array". How that actually happens would be host-defined, because we don't deal with I/O |
| 18:53 | <bakkot> | but also in practice I think ~all hosts which support imports would want this |
| 18:53 | <bakkot> | unless they have something bespoke going on where you can only import a specified set of built-in modules or something |
| 18:53 | <snek> | import "node:fs" with { type: buffer } |
| 18:54 | <bakkot> | :D |
| 18:54 | <nicolo-ribaudo> | That's to get fs API with Node.js Buffer instead of Uint8Arrays for reading files |
| 18:56 | <ljharb> | tbh we're (or would have been) the right venue for a lot of the things that browsers and server runtimes have added over the years |
| 18:57 | <bakkot> | I still have some faint hope that we can steal some of them |
| 18:57 | <bakkot> | like TextEncoder |
| 18:57 | <snek> | we can steal TextEncoder as part of type: text |
| 18:57 | <Michael Ficarra> | do we need a process document reading? |
| 18:57 | <snek> | and then engines will be forced to implement it which means we can write proper optimizations for it 😠|
| 19:00 | <ljharb> | did notes stop? |
| 19:00 | <Michael Ficarra> | no I see them |
| 19:00 | <Justin Ridgewell> | bakkot: I sent you a DM, but Matrix's UI is horrible for new chats and I don't know if you've seen it. |
| 19:00 | <ljharb> | hm i see "EAO: I fig my luck. So we can have stage one for this proposal but replacing" as the last bit |
| 19:01 | <ljharb> | nvm, a couple refreshes did it |
| 19:01 | <Michael Ficarra> | nope, refresh |
| 19:01 | <ljharb> | took like 5 |
| 19:01 | <bakkot> | nope and it's not even hidden, there's just nothing there |
| 19:01 | <Chris de Almeida> | works on my machine! |
| 19:01 | <Michael Ficarra> | you always have to do 5 to be sure |
| 19:01 | <ljharb> | only way to be sure |
| 19:01 | <Justin Ridgewell> | You have to go to the "Home" tab in Elements to see it |
| 19:02 | <bakkot> | you can dm on twitter or bluesky I guess? |
| 19:02 | <ljharb> | ok so this did get stage 2, yes? |
| 19:02 | <Justin Ridgewell> | I have neither. |
| 19:02 | <Chris de Almeida> | yes |
| 19:02 | <styfle> | So it sounds like we basically want to revert this PR, correct? https://github.com/styfle/proposal-import-buffer/pull/7 |
| 19:02 | <Chris de Almeida> | seems like it |
| 19:02 | <bakkot> | I did, nada |
| 19:04 | <nicolo-ribaudo> | Just use email folks |
| 19:05 | <Michael Ficarra> | the decision was a Uint8Array backed by an immutable ArrayBuffer IIRC |
| 19:05 | <nicolo-ribaudo> | So it sounds like we basically want to revert this PR, correct? https://github.com/styfle/proposal-import-buffer/pull/7 |
| 19:05 | <Justin Ridgewell> | We need something better than Matrix. |
| 19:05 | <nicolo-ribaudo> | We want to keep it immitable |
| 19:07 | <bakkot> | (but not itself a frozen object, i.e. people can still attach non-integer data properties) |
| 19:43 | <bakkot> | adding AI_POLICY. md as discussed yesterday: https://github.com/tc39/how-we-work/pull/164 |
| 19:58 | <Chris de Almeida> | we resume in < 2 mins |
| 19:59 | <Chris de Almeida> | cool people volunteer to help with notes. YOU can be a cool person too! |
| 20:01 | <nicolo-ribaudo> | Damn I was hoping to get the day back |
| 20:01 | <ljharb> | fast advancement of all 4 proposals tomorrow would mean you have most of the day back ;-) |
| 20:05 | <Mathieu Hofman> | Justin Ridgewell: can you remove my unthenable comment, it wasn't fully serious or worth of the time |
| 20:06 | <Justin Ridgewell> | Done |
| 20:16 | <ljharb> | i like the idea of fixing certain algorithms, fwiw |
| 20:16 | <bakkot> | Promise.resolveNotThennable? |
| 20:17 | <bakkot> | new Promise((res, rej) => {...}, true)? |
| 20:17 | <Mathieu Hofman> | I consider the general approach between Justin and I to be the same, just with slightly different actual resolutions |
| 20:18 | <nicolo-ribaudo> | I like Justin's idea but I'd like it to be spec-internal, i.e. we somehow guarantee that the promise returned to the user does not resolve with a thenable |
| 20:18 | <nicolo-ribaudo> | Otherwise .then(x => x) will start changing what the promise resolves to |
| 20:19 | <Mathieu Hofman> | Which is why I prefer the tick delay approach, so it doesn't leak out as much to the user |
| 20:21 | <ljharb> | if there's no solution that prevents a promise resolving to a thenable, then might i suggest there's no solution? |
| 20:22 | <Chris de Almeida> | help wanted: add a definition of thenable to https://github.com/tc39/how-we-work/blob/main/terminology.md |
| 20:22 | <Chris de Almeida> | related: https://github.com/tc39/ecma262/issues/2868 https://github.com/tc39/ecma262/pull/2869/files |
| 20:23 | <Andreu Botella> | WebIDL-defined methods can take promises, which currently accept thenables. AFAIK this is only ever used in WebAssembly.{compile,instantiate}Streaming, since it's supposed to accept the return value from fetch, but there might be code in the wild passing thenables to that |
| 20:23 | <Mathieu Hofman> | Unless we change the definition of thenable to exclude the objects that are "unthenable" by internal slot |
| 20:23 | <Mathieu Hofman> | But then we also need a predicate to test for that |
| 20:24 | <ljharb> | but then wouldn't that break userland thenables? |
| 20:24 | <ljharb> | because the check would then be typeof x.then === 'function' && Promise.isPromise(x) |
| 20:24 | <Mathieu Hofman> | unless they updated, yes |
| 20:24 | <ljharb> | like, it's actually a feature that userland thenables can exist, and i'd bet lots of code relies on it |
| 20:24 | <bakkot> | I think respondWith also takes a promise? |
| 20:25 | <bakkot> | https://w3c.github.io/ServiceWorker/#fetch-event-respondwith |
| 20:25 | <Andreu Botella> | oh, that's right |
| 20:25 | <bakkot> | (waitUntil is maybe a cleaner example) |
| 20:26 | <bakkot> | ugh I hate reading these specs, the prose is so imprecise |
| 20:28 | <bakkot> | anyway yeah it does new Promise(r => r(argument)) https://webidl.spec.whatwg.org/#js-promise |
| 20:28 | <bakkot> | I think this is unlikely to be buggy though, web idl argument coercion very often executes user code anyway so algorithms are presumably robust to that |
| 20:29 | <Michael Ficarra> | this isn't TC39 jargon, it's on MDN: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise#thenables |
| 20:30 | <bakkot> | our glossary can link MDN |
| 20:30 | <dminor> | Did we get Stage 2 reviewers for import buffer? |
| 20:31 | <Chris de Almeida> | no, and I blame whoever was chairing at the time, frankly /s |
| 20:31 | <nicolo-ribaudo> | No, I guess I can review though |
| 20:32 | <eemeli> | Who could help with renaming the proposal-measure repo as proposal-amount? |
| 20:32 | <Chris de Almeida> | /voluntell @ljharb |
| 20:34 | <ljharb> | on it … done |
| 20:36 | <eemeli> | Thank you! |
| 20:39 | <sffc> | If there's time, it would be helpful to discuss Waldemar's Intl MV issue: https://github.com/tc39/ecma402/issues/1017 |
| 20:42 | <ljharb> | so this was the new Global proposal, renamed to "proposal-module-global" that got stage 1? |
| 20:43 | <Zb Tenerowicz (ZTZ/naugtur)> | yes |
| 20:44 | <Aki> | germany-heavy showing there |
| 20:45 | <Chris de Almeida> | yes, confirmed this at the end of discussion |
| 20:45 | <Chris de Almeida> | timebox? |
| 20:45 | <sffc> | 20m? |
| 20:52 | <ljharb> | heads up to those with conditional advancement: please DM or ping me on matrix when the conditions are met, so i can update the proposals table |
| 23:41 | <styfle> | In the meeting today, someone (I think nicolo-ribaudo) mentioned that Uint8Array is preferred and then citied something but I don't recall what document they were citing. Does anyone know? |
| 23:42 | <Andreu Botella> | I think it's https://www.w3.org/TR/design-principles/#uint8array |