Dave Bakker

There's no immediate rush from my side, so feel free to take your time.

@alexcrichton > One comment I would have is that I think it would be best to implement this in a way that's not baked-in to wasmtime-wasi itself I agree. Continuing...

Coming back on my previous comment: Even though the initial refactor may be more work, I think it's more straightforward to forget about "interceptors" completely and put the entire socket...

#7705 contains the preparational work discussed further in this issue. We haven't started on the design in the initial comment

Hi @rylev . I raised a [similar issue](https://github.com/bytecodealliance/wasmtime/issues/7681) 4 days ago. Specifically the "Domain-based policy strategy" section from that issue. Just wanted to make sure we're not about to do...

@alexcrichton Option 4(?): Create a specialized `Wasi***View` per package/interface and place the extension points on that. Similar to `WasiHttpView`. No `Box`es or `Mutex`es required. Example for TCP: ```rs pub trait...

To those who are interested; I've created a draft proposal at: https://github.com/badeend/WASI-Networking

> for the preview2 timeframe I have advocated that we keep interfaces and concepts that existed in preview 1 as similar as we can possibly get away with. Yeah, that's...

I've created a proof-of-concept of this over at: https://github.com/bytecodealliance/wasmtime/compare/main...badeend:root-directory --- > We could add a plain `open` function, which takes a path argument and resolves it relative to a filesystem...

The POC also fixes https://github.com/WebAssembly/wasi-libc/issues/414, btw