InMemoryBolt

A Bolt whose segments live in memory — the reference implementation, and the one every target has, including the browser.

It writes the same bytes a disk-backed backend writes: the same segment header, the same length-prefixed, CRC-checked frames, the same canonical CBOR ops. That is deliberate rather than incidental. A reference implementation that kept ops as objects would leave the archive format unexercised until the first mmap backend existed, which is the worst possible moment to discover a field is missing from a format whose entire premise is that it is expensive to change.

Bounded, and honest about it. capacityBytes caps the whole archive; past it, append returns AppendResult.Failed carrying the dots it could not keep, and availability flips to BoltAvailability.Unavailable. An in-memory archive that grew without limit would be a memory leak wearing an archive's clothes.

On wasmJs this is the only bolt there is, and that is a real limitation

A browser has no filesystem, so neither memory-mapped backend compiles for wasmJs and this one is what runs there. It passes the whole conformance suite on that target — but it does not survive a page reload, which is a strange thing for an archive to be. A bolt exists so a server can hold a year of history beside a phone holding an hour; an in-memory one on a browser tab holds history for exactly as long as the tab does.

So on wasmJs, treat this as a working implementation of the contract rather than as durable retention. Durable retention there needs a different backend — see #2233. It is more tractable than "the browser has no filesystem" suggests: a browser lacks a filesystem, not durable storage, and this repo already ships a tested IndexedDB-backed store elsewhere.

Parameters