search

ipld / wasm-ipld

Tools and examples of IPLD codecs and ADLs in WASM callable from hosts
Apache License 2.0
8 stars 1 forks source link

Utilize The WRAP Standard #6

Closed dOrgJelli closed 2 years ago

dOrgJelli commented 2 years ago

Amazing project! I left a comment here regarding data marshalling, but feel there quite a few benefits that the WRAP standard can provide this project.

Creating this issue to share with you, explore what this might look like, and hopefully keep moving Wasm + IPFS forward!

aschmahmann commented 2 years ago

Thanks @dOrgJelli for the comment and suggestion. I tried following through the links but hit a bunch of dead ends on some of the specifications for what we might implement here. I'd like to learn more though.

IIUC (this was my first Rust or WASM project 😅) what's going on is that I've basically invented a few structures to deal with the fact that the WASM Component Model doesn't seem to exist yet and various tools that are advertised as helping developers deal with higher level abstractions than just integers (e.g. wasm-bindgen) don't actually commit to an ABI which makes them usable beyond their (generally single target) host language (e.g. Javascript) which in practice makes them unsuitable for building WASM code designed to run in multiple host environments (Go, JS, Rust, Python, ,NET, Java, ...). Examples of some of these hacky data structures include https://github.com/aschmahmann/wasm-ipld/blob/main/wasmlib/helpers/src/lib.rs#L17-L21.

What's here works, but is far from ideal. If there's a standard that could be used instead of the existing ABI that sounds great! If you could help me understand where this fits in with the component model proposal (e.g. is it an alternative because that group is moving too slowly, does it have a different mission/objective, etc.) that would also help.

Aside from some of the ABI bindings there's also WAC which you commented on the spec for. The idea there is to try and as faithfully as possible represent the IPLD Data Model in a serialized form so it can be moved across the WASM boundary easily. If there is another way to move the data into WASM that can be used to represent the IPLD Data Model in a birdirectional way (i.e. only one way to convert to or from the Data Model to the target form) that sounds interesting though.

dOrgJelli commented 2 years ago

"a bunch of dead ends" in the spec

Apologies I should have been clearer that we're actively building out different parts of the specification, but the toolchain is released and usable today. It supports building wasm modules in Rust & AssemblyScript, and running them in TypeScript / JavaScript (Python & Rust OTW soon).

I'd recommend checking out the docs here: https://docs.polywrap.io/

Wasm Component Model doesn't exist ... wasm-bindgen doesn't commit to an ABI ... running wasm in multiple host languages

At Polywrap we're addressing these developer pain points, and will gladly adopt any wasm community standards that come to fruition in the future, but are not waiting on them to make things usable today. I'd be happy to give you a tour of how we've architected solutions for:

represent the IPLD Data Model in a serialized form so it can be moved across the WASM boundary easily

Would be happy to show you how you can do this with our toolchain :)

Feel free to grab a time here that works best for you! https://calendly.com/dorgjelli

thewtex commented 2 years ago

Hey! I read your cool presentation ! And Polywrap looks amazing! They both seem to overlap to some degree with WASM Component Model / Interface Types. A humble plea from someone would like to use all these neat cross-language standards is to please try to converge on a common standard. @lukewagner @aschmahmann @dOrgJelli

aschmahmann commented 2 years ago

A humble plea from someone would like to use all these neat cross-language standards is to please try to converge on a common standard.

+1, as much as possible it'd be nice to share standards here.

There are a few folks interested in how IPFS and WASM might play together. It came up at the IPFS Thing 2022 event a couple weeks ago (https://2022.ipfs-thing.io/). Videos and other presentation materials for the event are still making their way online, but should be visible from https://discuss.ipfs.io/t/2022-07-15-ipfs-wasm/14642 when they are.

There's an ipfs-wasm channel on the IPFS Discord (https://docs.ipfs.io/community/chat/#discord), that'll soon be bridged to other community chats (e.g. Matrix + Filecoin Slack) where we can chat. Or if you'd prefer we can use the forums (discuss.ipfs.io). Don't want to kill any conversation here, just want to be more inclusive of other folks who are interested (and knowledgeable) in this topic and help us all learn a little more 😄.

dOrgJelli commented 2 years ago

Completely agree @thewtex, a common standard is certainly the ideal, and I think we'll arrive there soon with all of the great independent innovation happening around WebAssembly.

I'd be happy to move this conversation over to IPFS's Discord for more visibility. Additionally I'm going to close this issue as there don't seem to be specific next steps. Mainly created this to start a conversation 😄 appreciate your replies @aschmahmann 🙏