Hi, your friendly neighbourhood activist investor here.
I dunno the best way to contact, or who's in charge at the moment but what I'd like to do is migrate my https://github.com/dragginzgame/canic/tree/main/crates/canic-memory canic-memory library to be a wrapper around the stable-structures ids.
Maybe you can add the code into stable structures, up to you.
Here's the LLM breakdown :
Stable memory on the Internet Computer is persistent disk layout, but today most applications still treat memory ownership as an implementation detail derived from current source structure, package names, or runtime declarations. That approach is fundamentally unsafe for long-lived systems. Renaming a type, moving a module, rebuilding a registry from current declarations, or accidentally reusing a memory ID can reinterpret existing bytes as a different logical store, strand historical data, or silently corrupt state across upgrades. The ecosystem has strong stable-memory primitives through ic-stable-structures, but it does not yet have a durable allocation-governance layer that preserves historical ownership, validates upgrades against persistent history, or prevents storage ABI drift before code begins executing.
Our solution is to treat stable memory as a formal storage ABI with a persisted ledger that survives upgrades and becomes the authoritative historical record of memory ownership. The core invariant is stable_key -> memory_id forever: explicit stable keys become durable allocation identity, while crate names, type paths, and labels become non-authoritative metadata that may drift safely over time. The ledger persists allocation history, tombstones, reservations, schema metadata, and generation commits in stable memory, validates runtime declarations before endpoint execution, and fails closed if any historical ownership invariant is violated. This creates a storage-governance layer above ic-stable-structures that turns stable memory from a runtime convenience into a durable, auditable, rollback-safe allocation protocol for long-lived Internet Computer systems.
It's something I need for canic, but would be good if it could be considered to be part of the ic-stable-structure family.
When you've got an canister orchestration system that needs stable memories, then a database that needs stable memories, and then an application... it's a mess, and upgrading is a game of roulette.
Anyway, just a heads up. I'm going to separate the repo and work on it over the next few days, and then if you want to manage it, go for it. The code can be hammered and refined but won't really change until your wasm memory_id system does.
Hi, your friendly neighbourhood activist investor here.
I dunno the best way to contact, or who's in charge at the moment but what I'd like to do is migrate my https://github.com/dragginzgame/canic/tree/main/crates/canic-memory canic-memory library to be a wrapper around the stable-structures ids.
Maybe you can add the code into stable structures, up to you.
Here's the LLM breakdown :
Stable memory on the Internet Computer is persistent disk layout, but today most applications still treat memory ownership as an implementation detail derived from current source structure, package names, or runtime declarations. That approach is fundamentally unsafe for long-lived systems. Renaming a type, moving a module, rebuilding a registry from current declarations, or accidentally reusing a memory ID can reinterpret existing bytes as a different logical store, strand historical data, or silently corrupt state across upgrades. The ecosystem has strong stable-memory primitives through
ic-stable-structures, but it does not yet have a durable allocation-governance layer that preserves historical ownership, validates upgrades against persistent history, or prevents storage ABI drift before code begins executing.Our solution is to treat stable memory as a formal storage ABI with a persisted ledger that survives upgrades and becomes the authoritative historical record of memory ownership. The core invariant is
stable_key -> memory_id forever: explicit stable keys become durable allocation identity, while crate names, type paths, and labels become non-authoritative metadata that may drift safely over time. The ledger persists allocation history, tombstones, reservations, schema metadata, and generation commits in stable memory, validates runtime declarations before endpoint execution, and fails closed if any historical ownership invariant is violated. This creates a storage-governance layer aboveic-stable-structuresthat turns stable memory from a runtime convenience into a durable, auditable, rollback-safe allocation protocol for long-lived Internet Computer systems.It's something I need for canic, but would be good if it could be considered to be part of the ic-stable-structure family.
When you've got an canister orchestration system that needs stable memories, then a database that needs stable memories, and then an application... it's a mess, and upgrading is a game of roulette.
Anyway, just a heads up. I'm going to separate the repo and work on it over the next few days, and then if you want to manage it, go for it. The code can be hammered and refined but won't really change until your wasm memory_id system does.