Before a network can serve content reliably, it needs a precise way to identify and verify that content.
The storage acceptance records from February 25, 2026 cover an early foundation of ENTENCY GNS: turning bytes into chunks, chunks into objects, and objects into inputs that services can use.
This retrospective looks at that first boundary. The work established a common content model before broader hosting and network operation could be evaluated.
Starting with verifiable pieces
A local file path describes where one machine stores something. It does not give another node a portable description of the content or a way to establish that the returned bytes are correct.
The chunk engine introduced a split, hash and storage path. A manifest could then describe the chunks needed to reconstruct an object, while the object layer supplied a stable identity and resolution mechanism.
That gave the system a concrete validation question: do the retrieved pieces reconstruct the expected content?
The first acceptance suite answered it with a deterministic 6 MiB payload. The payload was ingested and rebuilt byte for byte. A separate scenario fetched chunks through a remote HTTP endpoint and checked the chunk hashes and tree root.
Making retention explicit
Correct retrieval is only part of storage behavior. The system also needs to know when content may be removed.
The garbage-collection acceptance scenario retained a chunk plan, ran a sweep and observed zero deletions. After the plan was released, its chunks became collectible.
This was a bounded test of retention and collection semantics. It did not establish long-term availability across independent providers, but it did give later services a tested local storage contract.
Moving services onto the object model
The object acceptance tests checked URI round-tripping, manifest resolution and byte-identical reconstruction. Resolution remained independent of higher-level streaming, compute, routing and identity services.
The next step connected services to that foundation. Streaming accepted an object reference, playback returned chunk-based segments, and compute resolved an object dependency. The service wrappers rejected raw local-path shortcuts where the object interface was required.
Storage, streaming and compute could now refer to content through a shared object model.
The recorded M1, M2 and M3 acceptance scenarios passed. Their significance was specific: the content model worked through the tested storage and service paths.
What remained beyond the foundation
These results did not prove a globally durable storage network, a production streaming service or live multi-provider hosting. Those require additional mechanisms and experiments around placement, replication, retrieval and failure.
What they supplied was the layer those experiments could build on: explicit content identity, verified reconstruction and services that used object references consistently.
The next challenge was keeping that content-related state coherent when nodes disagreed, chains changed and references expired.
Built in Public. Documented as we build.
Top comments (0)