Availability profile

This document is not normative. It describes the layers that hold the object bytes a Makechain commitment names, and the obligations a layer takes on when it serves a Makechain project. No obligation here affects block validity, and a validator that has never heard of any availability layer still agrees on every block. The document supports specification section 8 (commands, and PUSH in particular), section 15 (proofs, light clients, and publication receipts), and section 17 (node roles and the database set). Where a rule about chain facts is repeated here for context, the specification is the authority.

1. The model

There is no single availability layer, and the protocol assumes none.

• Any team MAY operate the availability layer for its own projects.
• A project MAY have several layers.
• Each layer discloses content fully, to selected parties, or not at all, under its own retrieval policy and its own authentication.
• The chain records no locator for a layer.
• A project's layers are announced off chain, by messages signed with the project's keys (specification section 8, off-chain signed messages).
• An on-chain locator is a possible later release, and is not part of the protocol today.

A layer is outside the protocol. It is described here because a publication is only useful if its bytes can be fetched by those entitled to them.

2. What the chain says, and what it does not

Everything in a block is public: commitments, ref names in bodies, collaborator accounts, and timing. Makechain has no public or private project classification, no visibility field, and no reader role. Its permissions govern publication and administration, not retrieval. Object bytes stay outside consensus.

Publishing an object hash neither makes its bytes available nor guarantees their confidentiality. Clients distinguish public chain facts from service-controlled object access. Privacy, in this model, means private bytes behind a public hash.

Object unavailability never changes the validity of a finalized publication. A commitment on chain implies nothing about object availability.

3. Obligations of a layer serving a Makechain project

Any layer that serves a Makechain project is expected to meet all nine obligations below. They are stated as a profile a layer either meets or does not; nothing here is enforced by consensus.

1. Content addressing and immutability. Objects are content-addressed by the commitment's native scheme and stored immutably.

2. Chain-authorized writes. Uploads and staging writes require the account's current on-chain writing authority, a compatible key capability and scope, and an ACTIVE project. Those facts are checked through the authenticated facade at a declared finalized checkpoint. The layer fails closed beyond its stated checkpoint-lag bound. Retrieval is governed by the layer's own access policy; the chain supplies no read ACL.

3. Service-level billing. Object storage and transport use service-level billing. The protocol does not meter object bytes, and no layer may authorize a service debit from an on-chain credit ledger.

4. No consensus answers. A layer never answers a consensus question. A client that needs to know whether a commitment was published asks the chain or the history query tier.

5. Publication completeness. A push is complete only when the objects are stored and the PUSH command is finalized. The client orders those two steps, and a layer may refuse objects whose project it cannot resolve.

6. Durable collection roots. Every commit finalized on chain and its full object closure are collection roots forever, independent of ref deletion, project freezing, or billing expiry. Retrieval indexes, and any delta bases they need, survive repacking. Admitted objects are pinned durably before storage is acknowledged. Finality is reconciled through a persisted watermark. The layer fails closed when root discovery is incomplete or when its chain watcher lags, so nothing is collected between storage acknowledgement and processing of the finalizing block. Finality never makes never-uploaded bytes available, and the layer says so.

7. No client bucket credentials. Clients never hold bucket credentials for a chain-published project. Every write passes through the layer's authorization, so a direct object-store transport is not an accepted path. Transport-level ref writes are staging operations or mirrors of finalized chain state, never an authoritative ref update.

8. Multi-tenant lookup. The layer is multi-tenant by project and exposes a lookup by (project, scheme, commit id) backed by a verified object-to-pack index. It distinguishes object presence from complete closure availability. A pack-existence check is not a commit-existence check, because a commit's id differs from its pack's digest, and a verified pack does not establish a named commit's closure.

9. Consistent access policy. A layer's access policy applies consistently to existence lookups, pack and object downloads, metadata, caches, and signed download URLs. Staging data is isolated until the layer's explicit publication step. Where access is restricted, knowing or publishing another project's object hash is not evidence of permission, and mixed-tenant packs must not disclose unauthorized bytes. Any chain facts consumed by that policy use verified state under a declared freshness bound. The policy itself remains layer-owned and never affects consensus validity.

4. Freshness and the authenticated facade

An upload-authority check is an authorization-critical read. Specification section 15 states the rule it follows: verified current state under a stated maximum lag, from an independently maintained checkpoint, never a fallback to older history. A layer that cannot meet its declared lag bound fails closed rather than admitting a write.

5. Reference implementation

mkit is the reference store. Its wire protocol (mkit.transport.v1 over Connect) is what stock mkit clients speak, and its objects are immutable and verified before storage.

The mkit reference server does not, on its own, meet the required chain-authorized writes, durable chain-derived collection roots, service-mediated storage, commit lookup, and staging isolation, which are obligations 2, 6, 7, 8, and 9: it has open write, a client-side object-store transport, reachability-only collection, and pack-level existence only. The vcs application fronts it. It adopts the Connect wire shape, checks on-chain writing authority, owns retrieval policy and service-level billing, keeps the commit index, and pins chain-reachable roots.

Public retrieval needs no on-chain reader role. Any restricted retrieval is a layer feature, not a protocol feature.