-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Utilize The WRAP Standard #6
Comments
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. 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. |
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/
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:
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 |
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 |
+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 |
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 🙏 |
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!
The text was updated successfully, but these errors were encountered: