It currently only consists of Hoot bindings to an ERIS implementation compiled to WebAssembly. Complete bindings to goblins (i.e. as provided by [goblin eris]( The patch. If a boolean value, or. )) will follow.
Initial idea was to compile the guile-eris implementation to WASM using Hoot and just provide suitable implementations of the cryptographic primitives in WASM land. However, some more issues surfaced: guile-eris uses SRFI-60 and some weird stuff from (rnrs io ports) which didin’t work with Hoot. We could have changed guile-eris to not use those things, but we took the rocky path. We implemented ERIS in Zig so that it can be compiled to WebAssembly by itself( zig-eris).
This may seem crazy and unnecessary, and probably it is. My motivation was to have an implementation of ERIS that can be used as a C library - mostly for finally getting ERIS over/in GNUnet working. It also makes ERIS usable from plain JavaScript. Another neat thing about the Zig implementation is that it does not do any memory allocation. This should make it go fast and make it usable from constrained contexts. See the announcment on the ERIS mailing list for more information.
From Hoot/Goblins it is straightforward to add necessary cond-expands so that the (goblins eris) module provides the same interface when compiling with Hoot or natively.
Another note on ergonomics: Working from Scheme and Hoot is a pleasure, working with Zig is nice. Working with the Javascript glue between the two is bloody hell. I’d really like to be able to link the two WASM modules (the Hoot application and the ERIS implementation) to a single WASM module. This would get rid of the JS interop/glue and would feel much nicer. If somebody knows how this might work, please let me know!
Regarding the issues with compiling guile-eris to Hoot as-is, I think it would still be worthwhile to work on this as it’s a good use-case for Hoot<->Guile compatibility. If you still have details about some of the incompatibilities it would be great to get some issues filed. SRFI-60 doesn’t seem to be too challenging as Hoot already has a lot of these procedures. (rnrs io ports), being an R6RS module, will probably take a bit more work. I know that (rnrs base) has trouble compiling right now, so that’s probably the blocker (I told Andy Wingo about this and he says this should be a change made to Guile as the implementation of (rnrs base) uses module introspection and it shouldn’t.)
Regarding combining two Wasm modules into one, I’m not aware of a tool that could do it today (a quick glance at the wabt and binaryen READMEs didn’t say so, anyway.) It might be possible with the following rough process:
Parse both binaries
Compute the max of all ids in the first module (types, funcs, etc.)
Renumber all the ids in the second module so they don’t conflict with the first
Do some magic to map exports to imports that are now part of the same module and rewrite all call sites to use the internal functions
There could very well be dragons here, though. This would all depend on Wasm multi-memory support, too, which apparently doesn’t work in WebKit yet according to this feature matrix.
Alternatively to making Hoot work with those modules, I think it would be pretty straight-forward to not use SRFI-60 and the R6RS modules in guile-eris (patches welcome! )
I was also a bit surprised that this is not something completely standard people do all the time.
Hoot also seems to have some WASM linking stuff: Linker (Guile Hoot) . But I don’t know (or think) it follows the conventions above.
I must admit that I am personally not so interested in WebAssembly that I want to figure all this out and experiment. But I think it would be a neat little thing to do: Link Hoot WASM modules with C/Zig code compiled to WASM with LLVM. Anyone up for such a little quest?
)