o8vm

Hibana now has the capability to build QUIC/HTTP3 in the manner of Hibana Choreography. Check it out here: https://github.com/hibanaworks/hibana-quic

Here is an example of how a protocol defined in Hibana can confine even an AI agent’s behavior within an explicit interaction flow.

https://github.com/hibanaworks/hibana-agent

From an AMPST perspective, the key idea is this: one global choreography is projected into role-local protocols (Agent/Browser/Human), with affine progression (each step is consumed exactly once).

  const LOOP_BODY: g::Program<LoopBodySteps> = g::seq(
      g::send::<Agent, Browser, BrowserAction, 0>(),
      g::send::<Browser, Agent, BrowserObservation, 0>(),
  );
  
  const ADD_TO_CART_APPROVAL: g::Program<AddToCartApprovalSteps> = g::seq(
      g::send::<Agent, Human, RequestApproval, 0>(),
      g::seq(
          g::send::<Human, Agent, ApprovalDecision, 0>(),
          g::route::<0, _>(
              g::route_chain::<0, AddToCartArm>(ADD_TO_CART_ARM)
                  .and::<SkipAddToCartArm>(SKIP_ADD_TO_CART_ARM),
          ),
      ),
  );

So even AI-agent behavior is confined by protocol structure: illegal traces (skip/reorder/reuse/wrong branch) are unrepresentable, not merely blocked by ad hoc runtime checks.

As another example, we’re also preparing `hibana-quic` (a QUIC implementation built with Hibana) for public release. It already passes interop tests with neqo.

Yes, good catch — that repo is currently private while we prepare it for public release.

Current status: we’re actively preparing `hibana-quic` for publication, and it is already passing interop tests with neqo. Please wait a little longer for the public release. Thanks for your patience.

Thank you — this is very helpful feedback.

You’re absolutely right that I led with terminology instead of value. A simpler way to describe it is:

Hibana helps prevent protocol drift bugs in distributed systems. You describe the interaction once as a global choreography, and each role gets a projected local API. Because steps are affine (consumed once), invalid transitions like skipping, reusing, or taking the wrong branch are rejected by the type/protocol model.

So the practical goal is fewer hidden state-machine bugs, with one global source of truth for interaction order.

I appreciate the suggestion, and I’ll explain it this way in the next write-up.

Hibana( https://github.com/hibanaworks/hibana ) is an Affine MPST runtime for Rust. The key claim is type-system guardrails. In Hibana software behavior is written as global choreography, projected into role-local sessions, and invalid transitions are rejected by the type/protocol model instead of being handled ad hoc at runtime.

As one concrete example, hibana-agent( https://github.com/hibanaworks/hibana-agent ) applies the same model to constrain AI-agent action flow with session-typed branching.

In simple terms, userland just issues syscalls to the kernel. For a command, this could be as straightforward as mkdir dir in the shell or mkdir("dir") in Rust code. While this seems simple, it's not particularly convenient. To enhance usability, we're modeling it after Rust's standard library. For example, having access to handy features like `DirBuilder` makes developing in userland more efficient (see https://doc.rust-lang.org/std/fs/struct.DirBuilder.html). Aligning with Rust's standard library has other benefits, too. One is the absorption of compatibility issues. Rust is compatible with various platforms, and handling compatibility at the level of the Rust standard library, rather than through syscalls or libc, can be more efficient. The goal is that Rust code used on one OS can be recompiled to work on my OS. From a unikernel perspective, recompilation is natural, and if we're only using Rust for development, it enhances safety. By the way, in my OS, libc does not exist. The user library, akin to Rust's std, acts entirely as a wrapper over syscalls.

octox aims to provide a user library similar to Rust’s std, but implementing it is somewhat difficult.

Oh, I see! Thank you very much. I'll add both later!

Thanks! Is this notation in the README not enough: https://github.com/o8vm/octox#license ?

I would like to implement a plan9-like OS someday!

Thanks！For me https://pdos.csail.mit.edu/6.S081/2020/xv6/book-riscv-rev1.p... was quite helpful! but Someday I will write a book on how to implement this OS step by step in Japanese.

octox is also different in that the kernel, userland, mkfs, and build system are all implemented in Rust, and I think it is also different at the type level, for example, octox using mpmc for Pipe, and using OnceLock and LazyLock for static variable initialization.