NetConection Implementation (RTMPx/RTMFP protocols and more), maybe a clean and easy Solution?

[ROBERT-MCDOWELL]

To all Ruffle developers, I suggest to contact urgently @zenomnt from zenomt/rtmfp-cpp#18 , he's not against to help the community to study on the WASM/WASI API potential and why not find a a way to use WASI API to allow WASM to create sockets and more... https://github.com/WebAssembly/WASI so we could have mayb a clear and very interesting solution to finish to implement AS2 AS3 API and even more as WASI can open the door to agnostic OS System Interface like Adobe AIR.

[lvyitian]

You can't use WASI in the browser, WASI is prepared for WASM usages beyond the browser.

[lvyitian]

The browser vendors would absolutely oppose adding an API to establish raw TCP connections. This is very dangerous, it can lead to unavoidable malicious behaviour from the malicious webpage.

[ROBERT-MCDOWELL]

@lvyitian maybe I'm wrong but WASI is especially a System Interface API that CAN be a capability extension for WASM under certain conditions like client confirmation or else. WASI standard is still in development and not a closed project. also, for Ruffle Desktop adopt a WASI standard avoids OS differences as WASI harmonizes and is also done to be OS agnostic.
https://antmicro.com/blog/2024/03/introducing-jswasi-a-wasm-runtime-for-browsers/

[lvyitian]

WebAssembly System Interface, or WASI, is a new family of API's being designed by the Wasmtime project to propose as a standard engine-independent non-Web system-oriented API for WebAssembly.
WebAssembly is designed to run well on the Web, however it's not limited to the Web. The core WebAssembly language is independent of its surrounding environment, and WebAssembly interacts with the outside world exclusively through APIs. On the Web, it naturally uses the existing Web APIs provided by browsers. However outside of browsers, there's currently no standard set of APIs that WebAssembly programs can be written to. This makes it difficult to create truly portable non-Web WebAssembly programs.
Similar to how core WebAssembly provides no ability to access the outside world without calling imported functions, WASI APIs provide no ability to access the outside world without an associated capability.

Can WASI apps run on the Web?

Yes! We have a polyfill which implements WASI and runs in browsers. At the WebAssembly level, WASI is just a set of callable functions that can be imported by a .wasm module, and these imports can be implemented in a variety of ways, including by a JavaScript polyfill library running within browsers.

And in the future, it's possible that builtin modules could take these ideas even further allowing easier and tighter integration between .wasm modules importing WASI and the Web.

[lvyitian]

For the Ruffle Desktop, there're already a lot of abstraction layers to keep the behaviour same in different platforms. They are equivalent to the WASI abstraction layer, just not so general.

[lvyitian]

The WASI in the browser is just a set of utility modules, it does not add any new capabilities to the WASM in the browser itself.

[lvyitian]

All the wasm modules in the browser have the exactly same capabilities as JavaScript has.

[ROBERT-MCDOWELL]

@lvyitian WASI can communicate with WASM in browser, like Flash AIR and Flash plugin in the past

[lvyitian]

WASI is just a set of interfaces, it relies on the syscalls on the target platform, if the target platform doesn't provide the required syscalls, then these features won't be available in WASI either.
Browsers don't have TCP/UDP/etc. sockets, so a WASI impl running in one can't provide that either.
The browsers will NEVER provide low-level network stack, this is a determined design.

[lvyitian]

WebAssembly is completely sandboxed, it is not like the browser plugins in the past, WASM is implemented upon the Web API which is exactly the same as JS. WASM modules will obey the restrictions of the browser strictly.

[ROBERT-MCDOWELL]

@lvyitian I know all what you saying don't worry. I just share what's is on the table today with WASM and WASI which still not wrapped and open to new API requests. if communication from Web Wasm can be done with WASI so the socket can reside ONLY in WASI and the JS sandbox is respected on all aspect. I think it will need a client confirmation to allow the capability as the camera/microphone or all capabilites that go beyond the sandbox.