Evaluate upgrading Wasmtime to using component model

[DougAnderson444]

Wasmtime is the first wasm runtime to work towards the component model.

Components can be written and run by various languages, which increases interoperability and flexibility.

Components can even be run in JavaScript

[dhuseby]

I'll take a look. My only concern is that wasm compiled from other languages is magnitudes larger than lock/unlock scripts written in web assembly text. I'm not sure how much of a concern that is if the wasm scripts are referenced by CID instead of having the wasm directly inside of the provenance log / IPLD data structure. For now, I'm choosing to use web assembly text embedded in provenance logs just for transparency sake but I can see how complex IAM and delegation applications would likely be written in a higher level language due to complexity.

[DougAnderson444]

I was mostly wondering about being able to run the providence log Rust code in the browser. The wacc VM is Wasmtime based which does not run natively in the browser, unless I'm missing something. Noted about the size, but if malloc is not needed my understanding is it can be quite condensed. Wasm components can also be written in .wat formats, though I don't have any experience with this yet. Another option might be to make the lock and unlock script in something like Rhai for Rust, then the whole plog could be wasm componentized and definitely run both server side and browser side. Not sure if there's a specific design reason for the scripts to be in wasm? If the whole code is compiled to wasm it should be just as portable. Some food for thought.

…

On Thu., Apr. 25, 2024, 16:38 Dave Huseby, ***@***.***> wrote: I'll take a look. My only concern is that wasm compiled from other languages is magnitudes larger than lock/unlock scripts written in web assembly text. I'm not sure how much of a concern that is if the wasm scripts are referenced by CID instead of having the wasm directly inside of the provenance log / IPLD data structure. For now, I'm choosing to use web assembly text embedded in provenance logs just for transparency sake but I can see how complex IAM and delegation applications would likely be written in a higher level language due to complexity. — Reply to this email directly, view it on GitHub <#1 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABTDW7LOVXDVTXZGFDZB6DTY7FSTNAVCNFSM6AAAAABGDBRZMSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZYGEZTEOJVGU> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[dhuseby]

The reason the scripts are in wasm is two-fold:

1. Wasm VM's have no API whatsoever built in. You can't do anything to affect the host system by default. This makes it a very secure environment for running arbitrary code from the Internet because there's basically no attack surface.
2. Wasm is quickly becoming a universal langua franca that can be executed in VMs, in browsers, etc. There's no reason we have to use Wasmtime. I think the provenance-log crate could be made no-std so that it can run in a browser VM. In that case the component model would be important as the lock/unlock scripts would be interacted with as wasm modules in the browser and would be executed in Wasmtime when not in the browser.

[DougAnderson444]

I've iterated on this idea and invited you to view the experimental repo here: https://github.com/DougAnderson444/comrade

Comrade is like WACC but with plaintext scripts that then run in Rust/Wasm in a sandboxed manner. It works quite well!

Comrade will run in Browser Wasm, as Wasm Component, or even an Extism component. It's pretty flexible.

[dhuseby]

I am planning to invest some time on this over the holiday season. Last winter I wrote all of the Multikey, Multisig, WACC, and Bettersign code. It's my plan to button up that effort and launch the Bettersign network and adopt this component model for scripts.

[DougAnderson444]

I think that's great!

Although, I should rename this issue to "wasm component compatible" instead:

You should know bundling the wacc logic into wasm components was my initial plan too, but as I dug into it, I decided an entire component was overkill for the script logic. Eventually went with Rhai, but yes it can also be done by composing wasm components together.

The downside of the latter approach is that users won't be able to write scripts "on the fly" (aka in the browser), the script authors will need to be developers who know how to compile to WebAssembly, etc. If this is your intent, then wasm components are fine (but still kinda overkill).

The comrade approach binds plain text scripts to the Rust functions using Rhai, giving a more flexible script writing approach. But one could argue that since anyone can write a script, there is a greater attack surface. I would argue that the plain text scripts are still content addressed, so it is fine. All comes down to use cases, intents, and threat model.

I think you should consider open sourcing the libraries to gain more input too. The Functional Source licence, is ...tuned for SaaS companies ... not ideal for companies that depend on other business models, such as ... library embedding., so although it may apply to the final app it's not really well suited for the building block libraries, as far as I can tell. There is still SO much code that needs to be written to use these libraries, there will be plenty to licence under FSL down the road. My $0.02 cents.

[dhuseby]

@DougAnderson444 will you send me a new invite to comrade?

[dhuseby]

I'm rethinking your proposal and I think it makes sense as long as we can secure the VM properly.

[DougAnderson444]

@DougAnderson444 will you send me a new invite to comrade?

Sure, done.

Also, since the basis of comrade is pure text, we could probably write a macro which puts the text in some Rust which builds to wasm... We could make the two systems interop I think. CIDs give us a lot of flexibility.