IRC channel logs
2024-05-13.log
back to list of logs
<dthompson>theruran: hoot's wasm interpreter is for testing purposes. it's slow. <theruran>looks like Bytecode Alliance is pushing for object-capabilities in WASM 'nanoprocesses' <theruran>oh, planned Hoot feature: "Otherwise on WASI hosts we expect to have a WASI-specific support module eventually." <theruran>also see this on the README: "By the end of 2023 all common web browsers will support the WASM capabilities Hoot is using, but currently Chrome Dev and Firefox Nightly are the browsers to use." but according to the v0.4.1 release notes, it supports Firefox 121+ and Chrome 119+. Should I make a pull request? :) <dthompson>theruran: oops, looks like I missed that the last time I was updating the readme. a PR would be great! thank you for noticing! <dthompson>re: WASI: yeah it's something we could do eventually maybe but WASI is very different from what we do now <dthompson>don't have a strong use-case for it currently <dthompson>I'm curious what bytecode alliance is doing that's different from status-quo wasm... wasm module imports are already a type of capability system <theruran>GitLab requires a phone number and payment method to verify my identity? ha, I'm out. <dthompson>I definitely do not have any payment method associated with my account <theruran>dthompson: happens. they start adding the requirements without requiring it of existing users <theruran>I used to have a GL account but I deleted it <theruran>I had to verify my identity with GH to keep my student benefits. Or they were going to delete my private repos, or make them public? who knows. <dthompson>from a search some people say that you shouldn't have to put in a payment method <theruran>I didn't get that far. Saw it was the next step after phone number and I didn't feel like giving GitLab my phone number either. <theruran>from the Bytecode Alliance blog: > It’s still just WebAssembly, but it follows a particular pattern. And if we build this pattern into the tools and conventions we use, we can make third-party code reuse safe in WebAssembly in a way it hasn’t been in other ecosystems to date. <theruran>> Sidenote: At the moment, every nanoprocess is made up of exactly one wasm module. In the future, we’ll focus on toolchain support for creating nanoprocesses containing multiple wasm modules, allowing native-style dynamic linking while preserving the memory isolation of nanoprocesses <dthompson>I think it's just for a one-time code for the phone number <theruran>I had a hard enough time enabling all their JavaScript just to pass through the initial signup, where your name is also required. <dthompson>from a quick scan of the bytecode alliance page it seems like this is more of a wasm linear memory thing than a wasm gc thing <dthompson>there's a bit of split in the wasm community <dthompson>the wasmtime/embedded people don't really care about dynamic languages and web browsers, generally <dthompson>like a lot of these infographics and stuff are speaking in linear memory terms <dthompson>whereas gc'd heap objects allow fine-grained memory safety <dthompson>the "nanoprocess" thing is sort of like what we want to achieve with our secure Scheme project called Oaken <dthompson>where you can run an arbitrary chunk of code and be confident that it cannot do more than what it has been given the capabilities to do <dthompson>wasm modules are a great modern example of such a system <jfred-linode>is there any way you could somehow compose modules written in linear memory wasm and GC'd wasm? <dthompson>they all exist in wasm so you can combine them if you'd like <dthompson>hoot uses its own chunk of linear memory for storing unboxed values, for example <jfred-linode>It does seem like it could be interesting if Hoot programs could make use of components written in C, Rust, etc while maintaining all the capability-safe stuff. Since there's likely to be a lot of those I think <theruran>oh, I don't see anything published about Oaken but I vaguely remember it being mentioned <dthompson>jfred-linode: we can do this now if we needed <dthompson>jfred-linode: yeah it's free basically. a wasm module is a wasm module. <dthompson>you can take the exports from one and wire them up to the imports of another, provided type signatures match. <cwebber>lol that image. RUST C++ RUST C++ GO GO <dthompson>for example, you could take a wasm module containing libsodium and import the necessary functions into a hoot module <dthompson>you'd then have access to libsodium crypto in scheme <theruran>does Hoot enable composable WASM VMs? that's how I was understanding Bytecode Alliance's explainer there. object-capabilities for mutually-untrusted modules that may even be hosted by WASM VMs themselves. <theruran>or is there's a virtual architecture crammed into 1 WASM VM? I can't tell. <dthompson>one processing hosting more than one wasm engine would seem odd to me. I think they're saying that one process can host many mutually-untrusted wasm modules. <theruran>with many WASM VMs you could have 4GB addressable for each one, and they could be remote/local? <dthompson>iirc the component model people were opposed to the strings we wanted lol <jfred-linode>and it restricts exports of memory from modules (which apparently core wasm modules can do) <dthompson>yeah you can export a memory object, which makes sense to me. <dthompson>you just wouldn't want to share those with whoever! <dthompson>but yeah with linear memory you really don't have fine grained control over what memory another module could read/write <dthompson>if you share a memory, the receiver gets the whole thing <dthompson>gc managed objects are far superior for security <jfred-linode>so seems like they're trying to get folks to only communicate via imports/exports, which feels good from an ocap perspective <dthompson>yeah that's how wasm modules work presently. I don't know what the value-add of the component model is. <jfred-linode>I mean, it does feel to me like there's some value in *only* allowing the safe thing. Prevents component authors from going "you're going to import this from a C program right?" and giving you a big block of memory <theruran>"Moreover, a component interacts with a runtime or other components only by calling its imports and having its exports called. Specifically, unlike core modules, a component may not export Wasm memory, and thus it cannot indirectly communicate to others by writing to its memory and having others read from that memory. This not only reinforces sandboxing, but enables interoperation between languages that make different assumptions <theruran>about memory - for example, allowing a component that relies on Wasm GC (garbage collected) memory to collaborate with one that uses conventional linear memory." <dthompson>you would like a program that can sort a list of numbers, but you don't trust the code and you need to sort credit card numbers. how do you create a system that can allow you to run that code whilst eliminating the possibility of that code exfiltrating sensitive data? <dthompson>to solve that problem in wasm, the sorting program would be isolated in a module that never receives any imports for I/O so even if it contained code that tries to exfiltrate the info it can't <dthompson>that shows some care to not tie everything into a linear memory world <dthompson>the import/export system is great because it's the host that decides what imports a wasm module gets. a malicious module could declare an export called "phoneHome" but the host has to provide the implementation! <dthompson>it's like how when you call 'map' you have to provide the function that transforms one value into another. <dthompson>not many non-browser runtimes support either yet <jfred-linode>yeah, I hadn't realized that until I looked at its readme and saw both mentioned <jfred-linode>it does feel like the bytecode alliance folks are trying to keep both GC and linear memory wasm in mind, and that they're trying to ensure interop between them is possible <theruran>they have an Interface Description Language defined (WIT) and a Canonical ABI. so I like where this is going. <dthompson>I still just don't really get it, but I understand that some people want something like POSIX but for wasm <theruran>I like the idea of targeting both bare-metal/hypervisors and web browsers <dthompson>in practice you'll need two separate builds to do this. one of the web and one for native runtimes <theruran>the IDL and ABI definitions seem to me to be an effort to move away from POSIX and the mythical C ABI <jfred-linode>maybe someday we'll have an OS that runs wasm programs natively ;P <dthompson>if hoot were to get WASI support (or whatever interface wins) it would be a separate target. <theruran>dthompson: separate target makes sense, because different external resources need to be linked <dthompson>emscripten uses different system triplets for wasi vs. web presently <jfred-linode>right, that makes sense - I do remember reading some docs on wasm and seeing wasi/emscripten as separate build targets <theruran>but the WASM module, it may just see 'screen' and 'standard-input' and 'cursor' or whatever <dthompson>hoot on wasi would need some different way to be provided things like a bigint implementation <dthompson>like maybe you'd compile gmp to wasm and link that someone... idk how it would work <jfred-linode>ah, I guess in the browser you're making use of the browser's bigint implementation? and since scheme has bignums by default you'd need an implementation outside the browser? <dthompson>and the browser is a programmable host environment. you can do so much with js. those native wasm runtimes are not, and that's where WASI and co. come in <dthompson>they need some system by which you can link wasm modules together to do things 