Aotokitsuruya is learning

In Kobako: Exchanging Memory in WebAssembly we solved the problem of Ruby and WebAssembly interacting, and gave Ruby and mruby the ability to exchange values with each other, which basically cleared up the “sandbox” problem.

Sumitsubo is the tool I use to turn a “spec” into code that can actually be verified.

Midway through building Kobako, the question of whether the spec and the implementation were still aligned kept bothering me.

The past few posts covered how MessagePack was chosen, but interacting through WebAssembly works a little differently from interacting with a native extension.

Last weekend at COSCUP I gave a talk, “Let AI Take Over Your Application: Building a Seamless, Microsecond-Scale Ruby Sandbox,” covering some of the considerations behind Kobako’s design.

Choosing mruby as the sandbox language came out of ruby.wasm’s limitations, but sharing the same language standard (ISO/IEC 30170:2012) with CRuby doesn’t mean the goal comes easily.

I’ve been working on Kobako for a few months now, and I’ll also be presenting the project at COSCUP.

Kobako is a sandbox I recently built on WebAssembly and mruby for the Ruby ecosystem, in support of Harness Engineering, to fill the gap where AI-written code has no safe environment to run in.

Developing Kobako has surfaced quite a few interesting cases.

Last week I published Kobako: Letting Agents Safely Operate Rails, introducing the goals of the Kobako gem.