A topic to discuss all things Web Assembly in relation to Safe Network and its API.
This post is a Wiki so feel free to add links and update to help people arriving here. For example…
To-do
brief explanation of web Assembly
links to further reading / examples
summary of ways it could be used related to SN
explain WASM (Web Assembly) v WASI Web Assembly Systems Interface
Web Assembly Reading
WASI Preview 2 (announcement, January 24th 2024) featuring a cross language composable, component model with capability based interfaces and virtualization.
@joshuef I’ve had a quick look and built the merged WASM/WebSockets support for sn_client.
Am I right to assume this can’t talk to the network because that would require TCP or even WebSockets in safenode, and so is mainly about showing that it’s possible to build for WASM but not for anything useful? Or is there a way to use this with a Quic based safenode network?
Hmhmm - did I read correctly that with wasm we wouldn’t have multi processing capabilities?
(would be a bit a downer with self encryption of larger files and/or generally when processing a lot of files I’d guess…)
Well… Then I guess I should try to find the time to look into the sn_client and try to get a C FFI lib out of it
@joshuef got this with QUIK just this week Mark. It’s shaky still (nit quic, just wasm) but very promising.
From chatgpt @riddim (I also did a bit of stackoverflow and google and it is possible, but not yet simple as far as I can tell. )
Wasm, short for WebAssembly, is designed to be a portable compilation target for high-level languages like C, C++, and Rust, enabling deployment on the web for client and server applications. It’s important to understand that Wasm itself is not inherently multi-threaded or single-threaded; rather, it provides a platform for code that can be executed in a multi-threaded or single-threaded context depending on the environment and the way it’s programmed.
Here’s how Wasm relates to multi-threading:
Environment Support: Whether Wasm can handle multi-threading depends on the environment it’s running in. In web browsers, for instance, multi-threading support in Wasm is tied to the browser’s support for Web Workers and SharedArrayBuffer. This is because the main JavaScript environment is single-threaded, and multi-threading is achieved through Web Workers.
Language and Compilation: The programming language used to write the code that compiles to Wasm, and the compiler itself, play a critical role. Languages like Rust and C++ support multi-threading, and when compiled to Wasm, they can maintain this capability if the target environment supports it.
Shared Memory and Atomics: Wasm has added support for shared memory and atomic operations, which are essential for multi-threading. Shared memory allows multiple threads to access the same memory space, and atomic operations ensure that operations on shared data are executed without interference from other threads.
Performance Considerations: While Wasm can support multi-threading, there are performance considerations to keep in mind. The overhead of communication between threads and the cost of synchronization need to be balanced against the benefits of parallel execution.
Development and Debugging: Multi-threaded programming, in general, is more complex than single-threaded programming. This complexity extends to Wasm. Debugging and maintaining multi-threaded Wasm applications can be challenging.
In summary, Wasm can handle multi-threading, but its ability to do so is dependent on the environment it’s running in, the programming language and tools used to create the Wasm code, and the specific use case and performance considerations of the application. As an engineer and computer programmer, you might find exploring the capabilities of Wasm in multi-threaded applications particularly interesting, especially given its growing role in both web and server-side programming.
That’s what I was referring to and asking him about.
I think @riddim is inferring from the announcement linked in the OP, which describes plans for async in Preview 3 (c. end 2024). But of course that doesn’t prevent use of WASM within another threaded language.
BTW I don’t think it is wise to paste blocks of ChatGPT output in this kind of context because we know it contains errors, unless the content has been verified of course.
Actually I was inferring from @joshuef and your discussion in the wasm pull request @happybeing … Something about challenges with ‘concurrency’ made my head think about multi threading and Javascript and that I something had in mind that client side Javascript was not able to do multi processing…
Which made me ask chat gpt about wasm… And the answer was pretty similar to what @dirvine got there…
Probably there are ways to get stuff going… But nothing simple or straightforward… (and then again… Maybe we don’t need to have the most performant/ideal implementation from start… Something easy to use and reliable in function will most certainly be key… Improvements can come thereafter… )
I would say the cross X thing is worth a wee bit of slowdown actually. I expect with llms helping code these days that many projects will iterate quickly and projects will move on much faster. At least I hope so.
It’s also great for us if we move more wasm/wasi to have folks building and finding issues that we can all learn from . The FFI route is just so painful
And outside of singulary actions clients can probably parallelize stuff inside of app logic too… So maybe parallel processing being part of the library is not even really needed in the end
It can’t talk to defaultsafe_network, it can talk with the websockets feature.
To clarify this. In main we now have quic as a defauly, or websockets as an alternative feature for network transport layers.
websockets is used if you compile for wasm , and so you’ll need the same layer in the main network to use this.
We should be able to have both quic and websockets comms at nodes down the line if that seems worthwhile and viable perf wise.
This was me talking 'can we GET in any wasm supporting browser?as a tiny project to push forwardwasm`. And basically getting us to a state where we can (although rather poorly just now).
@riddim as I understand, browser cannot easily do concurrent work. So by default not. But webworkers are a thing. So I think something could be possible there.
I think though, large uploads will likely not go via the browser… (or they’d be better done elsewhere, perhaps).
Sure thing… But using the wasm build e.g. From python might be easier (e.g. No separate binaries for different platforms) than using any other form of api too…
And just having a simple blob/key-value-store without having to host anything / using any third party providers… Would be pretty cool
For sure. That could/would and hopefully will happen!
We’d need to set up proper wasm-target builds I think (rather than unkown-unkown), and there’s probably some nuance there in getting those builds right + testing. But certainly possible, it seems
No stupid questions, not true I disagree and this is probably one hence I preface it with that!
What data am I linking to? Is that just a pic or a video or a wasm binary ie a app?
All new to me so excuse the learning curve.
Hey Josh, “that” is the data address here, await safe.get_data("/ip4/127.0.0.1/tcp/59324/ws/p2p/12D3KooWG6kyBwLVHj5hYK2SqGkP4GqrCz5gfwsvPBYic4c4TeUz","9d7e115061066126482a229822e6d68737bd67d826c269762c0f64ce87af6b4c")
Is that an app compiled to wasm that will then load in the browser, am I misunderstanding this, I think that I am.
So, in the linked repo there, you havea. webapp, taht can load a sn_client built for wasm and use it in the browser.
Then, in the browser, with your compiled wasm code, you can run the above in a browser console to see it attempting to fetch data.
The second part there being eg 67d6b3ce2b589771b493b8ce0639d80e5f57da3a68362199c3b148c0e83dde1e as found:
**************************************
* Uploaded Files *
* *
* These are not public by default. *
* Reupload with `-p` option *
* to publish the datamaps. *
**************************************
"IMG_0093.jpeg" 67d6b3ce2b589771b493b8ce0639d80e5f57da3a68362199c3b148c0e83dde1e
