Consent-Keyed Immutable Storage Loops

Abstract

A consentful storage system should not ask only, “Who has the file?” It should ask, “Can the next access loop close?”

This proposal describes a Consent-Keyed Immutable Storage Loop: a storage-forward version of Abracadabracadoo in which immutable artifacts are preserved as history, while future access depends on a live, scoped, witnessed admissibility loop.

Version 0.2 adds a sharper witness architecture.

The witness should be as close to no-storage as practical. It should hold private keys or root secrets, not private records. Its records live on immutable public or encrypted storage. To regain access to its own operational state, a witness must be re-entered by other witnesses. Then, and only then, may it witness a storage access ceremony.

The minimum live pattern is:

A + B witness C's re-entry.
C witnesses the storage access.
All receipts are written to immutable storage.

This creates a recursive but bounded witness cell:

No witness witnesses alone.
No witness witnesses itself into authority.
No witness witnesses storage access unless already re-entered by others.

This is not a production cryptographic specification. It is a protocol shape. The present design uses familiar primitives — deterministic child derivation, passwords or local secrets, TOTP-like paired codes, signatures, content addressing, immutable logs, and witness receipts — as placeholders for reviewable protocol roles.

The core claim is narrower than “cryptographic control over information.”

The claim is:

Immutable artifacts preserve history; current admissibility governs whether this protected storage loop may lend fresh authority to a past artifact.

The reason this exists

Mutable storage quietly conflates several different operations:

changing a thing
replacing a thing
deleting a thing
revoking access to a thing
proving what happened
deciding what is still allowed to happen

Those are not the same operation.

A consentful system should keep them separate.

In ordinary storage, “delete” is often treated as a magical undo. But reality is not magical. Once a file has been read, copied, cached, indexed, trained on, printed, screenshotted, or remembered, the prior state cannot be cryptographically un-happened.

The honest primitive is not erasure of history.

The honest primitive is future-facing admissibility.

So this proposal begins with a different storage ethic:

Immutability preserves history. Consent determines whether this loop may continue lending authority to history.

That makes revocation cleaner. Revocation is not pretending the old artifact never existed. Revocation is refusal to let an old authorization keep closing new loops.

Cryptographic humility

This proposal intentionally does not claim cryptographic completeness.

The present vocabulary uses familiar primitives because they are available and understandable:

BIP32-like child derivation
TOTP-like paired codes
passwords or local secrets
public/private key signatures
content-addressed storage
append-only logs
witness receipts

But those primitives are not claimed to be sufficient as written.

A TOTP-like code is not consent. It is, at most, a liveness or paired-presence signal. A BIP32-like derivation path is not revocation by itself. It is, at most, a familiar way to think about scoped lineage. A password is not proof of human freedom. A signature is not proof of human understanding.

The protocol therefore uses careful language:

Not: cryptographic guarantee of consent.
But: machine-enforceable approximation of admissibility.

Not: total revocation of information.
But: denial of future authorized loop closure within this protocol boundary.

Not: the witness proves moral consent.
But: the witness attests a bounded ceremony against derivable state.

Any real implementation would require cryptographic review, threat modeling, coercion analysis, metadata review, and recovery design.

Relationship to Abracadabracadoo

Abracadabracadoo is a witness-centered loop: a proof-bearing layer that says, in effect, “this interaction occurred under these conditions, and a witness can verify the access event.”

This proposal turns that pattern storage-forward.

Abracadabracadoo:
  witness-held proof that a loop occurred

Consent-Keyed Immutable Storage:
  immutable artifact whose future access depends on a witnessed loop

Version 0.2 adds a deeper recursive condition:

A witness-held proof is stronger when the witness's authority to witness
was itself recently witnessed.

So the full pattern becomes:

proof of witness re-entry
  + proof of storage access ceremony
  + immutable artifact lineage
  + current manifest state
  = verifiable participation in a bounded access loop

Core intuition

A file should not open merely because a person, app, server, token, or old credential possesses access material.

It should open only when the relevant loop still closes:

the wallet says:          right lineage
the local secret says:    human-side participation
the re-entry witnesses say:
                          this access witness is awake, bounded, and current
the access witness says:  this storage ceremony occurred
the manifest says:        this is the current admissible head
the consent rule says:    this loop may close

If one of those fails, the future loop does not close.

Definitions

Artifact

An immutable encrypted object stored in public cloud storage, content-addressed storage, object storage, append-only storage, or another persistence layer.

An artifact may be historical, current, superseded, revoked, sealed, or quarantined. It is not edited in place.

Public immutable store

The shared persistence layer where artifacts, manifests, receipts, checkpoints, revocations, encrypted logs, and public commitments live.

The store may be public. The data in it need not be plaintext. Public storage means public availability and verifiability, not public readability.

Manifest

A signed, append-only pointer or index that identifies the current admissible artifact for a given scope.

The manifest is the living boundary of the storage loop. The artifact is what happened. The manifest says what currently counts.

Wallet root

A user-controlled root authority from which scoped child keys or equivalent scoped authorities can be derived.

The wallet root should not be used directly for storage encryption. It should derive or authorize scope-specific child material.

Wallet child key

A scoped child key, child authority, or child identity derived for a particular context, such as:

wallet-root
  / project
  / storage-domain
  / collection
  / file-or-loop
  / epoch

The purpose of child paths is influence-radius reduction. A revoked file, folder, project, relationship, or epoch should not require destroying the whole identity.

Human-held or local secret

A password, passphrase, local device secret, hardware-backed unlock, biometric-gated local release, or equivalent human-side participation factor.

This prevents the wallet child key alone from being enough.

It does not, by itself, prove consent.

Witness

A Witness is a minimally stateful re-entry function that converts a bounded ceremony into a durable artifact.

It does not store the file. It does not own the plaintext. It does not decide human consent. It does not serve as the system’s private memory.

Instead, the Witness re-enters the immutable artifact field, reconstructs the relevant admissibility state from public or encrypted logs, verifies the presented ceremony according to published rules, and emits a narrow receipt of what it can attest.

A witness should keep secrets, not records.

Records belong to the immutable substrate.

The witness’s role is to derive, verify, attest, and forget.

Witness re-entry

Witness re-entry is the process by which a witness regains operational continuity.

A witness may possess private key material, but private key possession alone is not full witness authority. To become operational for a bounded epoch or scope, the witness must be re-entered by a separate quorum of witnesses.

The minimum pattern is:

A + B re-enter C.
C may now witness a bounded storage ceremony.

Re-entry witnesses

The witnesses that admit another witness back into operational continuity.

They do not directly witness the storage access event. They witness the access witness becoming current, bounded, and operational.

Access witness

The re-entered witness that observes the storage ceremony itself.

It should be separate from the witnesses that performed its re-entry.

Witness cell

A small quorum of witnesses in which each witness can regain operational continuity only through bounded re-entry witnessed by the others.

The smallest mutual cell is a triangle:

A is re-entered by B + C.
B is re-entered by A + C.
C is re-entered by A + B.

But the storage access pattern separates roles:

For event 1:
  A + B re-enter C.
  C witnesses storage access.

For event 2:
  B + C re-enter A.
  A witnesses storage access.

For event 3:
  A + C re-enter B.
  B witnesses storage access.

The currently valid rule set determining whether the next read, write, update, share, rotate, recover, or revoke loop may close.

In this protocol, consent state is treated as machine-enforceable admissibility, not as the whole human reality of consent.

Witness receipt

A durable artifact emitted by a witness.

It should attest only what the witness can honestly derive, verify, or observe.

It should not claim to prove total human consent.

The no-storage witness model

The witness should be as close as possible to a no-storage service.

It may hold:

private signing keys
root witness secrets
paired-code seeds or equivalent liveness material
configuration for locating immutable logs
minimal local boot material

It should not hold:

plaintext files
user documents
private access histories as a database
global mutable state
user passwords
raw decrypted logs longer than needed
unnecessary metadata

The witness boots, finds its root key material and relevant paired-code seeds, locates the immutable public store, reconstructs state from artifacts, performs its bounded role, emits receipts, and discards ephemeral state.

The witness does not remember by possession.

It remembers by re-entry.

Witness is not memory.
Witness is re-entry.

The witness cell

A single witness is too sovereign.

A self-certifying witness is worse.

So version 0.2 introduces the witness cell.

The witness cell is a small mutually constraining group in which no witness can witness alone. Each witness may hold its own private key material, but operational authority must be reconstituted through witnessed relationship.

The key invariant:

Witness authority is not held.
It is reconstituted.

A private key proves lineage:

I am this witness identity.

A re-entry quorum proves relational continuity:

This witness identity has been admitted back into the present.

A storage access receipt proves event collapse:

Given that witnessed re-entry, this storage ceremony was observed.

The authority stack is therefore:

private key        = identity continuity
public store       = artifact continuity
peer quorum        = relational continuity
re-entry receipt   = operational continuity
access receipt     = event collapse

Why re-entry and access witnessing must be separate

A witness must not certify its own authority and then immediately treat that self-certification as sufficient proof.

So the protocol separates two functions:

1. Witness re-entry
   Other witnesses attest that a target witness has re-entered operational continuity.

2. Storage access witnessing
   The re-entered witness attests that a storage ceremony occurred.

The minimum live pattern is:

A + B witness C's re-entry.
C witnesses the storage access.

A and B do not witness the file.

They witness C’s fitness to witness.

C does not self-certify.

C witnesses the file ceremony after re-entry.

The immutable store preserves both artifacts:

1. C re-entry receipt
2. storage access receipt signed by C

The core rule:

A witness may not witness storage access unless its own re-entry was already witnessed by a separate quorum.

A shorter form:

No witness witnesses unwitnessed.

Re-entry receipt

A witness re-entry receipt is emitted when a quorum admits a witness back into bounded operational continuity.

A conceptual public receipt may look like:

witness_reentry_receipt:
  receipt_type: "witness_reentry"
  protocol: "ckisl"
  protocol_version: "0.2.0"
  target_witness: "C"
  reentry_witnesses:
    - "A"
    - "B"
  checkpoint: "latest recognized immutable log checkpoint"
  scope_commitment: "opaque or blinded scope identifier"
  epoch: "bounded time, log, or ceremony window"
  request_commitment: "hash of full re-entry request"
  result: "reentered | refused | indeterminate"
  signatures:
    - "A signature"
    - "B signature"

The public receipt should minimize metadata. Human-readable context, private scope details, and refusal reasons may live in encrypted companion artifacts.

Storage access receipt

A storage access receipt is emitted by the access witness after it has been re-entered.

It should point backward to its re-entry basis.

storage_access_receipt:
  receipt_type: "storage_access"
  protocol: "ckisl"
  protocol_version: "0.2.0"
  storage_witness: "C"
  reentry_basis:
    reentered_witness: "C"
    reentry_witnesses:
      - "A"
      - "B"
    reentry_receipt: "hash of A+B-to-C receipt"
    epoch: "bounded time, log, or ceremony window"
  storage_scope_commitment: "opaque or blinded scope identifier"
  manifest_head: "hash of current manifest head"
  object_reference: "optional content hash or encrypted reference"
  request_commitment: "hash of full storage request"
  ceremony_type: "read | write | revoke | rotate | recover | checkpoint"
  result: "observed | refused | indeterminate"
  signature: "C signature"

A verifier can then ask:

Was C validly re-entered before C witnessed this access?
Was C's re-entry bounded to this scope, epoch, or ceremony?
Does the storage receipt point to that re-entry?
Do the manifest and object references match the immutable store?

Protocol sketch

1. Establish a storage scope

A user creates or selects a storage scope.

scope_id = hash(project_id, storage_domain, collection_id, file_id)

A wallet child authority is derived or selected for that scope.

wallet_child = derive(wallet_root, scope_id, epoch)

This sketch uses deterministic derivation as a conceptual lineage placeholder. It does not specify a production-safe derivation method.

2. Create an immutable artifact

A file or structured record is encrypted locally.

The safer conceptual direction is to generate a random per-artifact data-encryption key and then seal or wrap that key under a scoped access policy.

artifact_key = random per-artifact key
ciphertext = encrypt(artifact_key, plaintext, artifact_context)
object_id = hash(ciphertext)

The object is written to immutable public storage.

Public storage does not mean public plaintext.

3. Publish or update the manifest

A manifest identifies the current admissible object for the scope.

manifest_head:
  scope_commitment
  current_object_id
  policy_id
  epoch
  previous_manifest_head
  signatures

The manifest is append-only. Updates produce new manifest heads rather than mutating old ones.

4. Re-enter an access witness

Before storage access can be witnessed, an access witness must be admitted into operational continuity.

Example:

A + B re-enter C.

A and B verify what they can:

C identity or key lineage
requested scope or scope commitment
latest recognized checkpoint
freshness of request
absence of known revocation
bounds of epoch or ceremony

A and B emit a re-entry receipt.

C can now act as access witness for the bounded scope, epoch, or ceremony.

5. Request storage access

The user or agent requests a read, write, revoke, rotate, recover, or checkpoint operation.

The request includes commitments to relevant context:

operation
scope commitment
manifest head
object reference
wallet child proof or signature
local participation proof
fresh challenge or paired-code event
policy version

The access witness does not need plaintext.

It needs only enough to attest that the bounded ceremony occurred against the current derivable state.

6. Witness the storage ceremony

The access witness verifies the request according to published rules.

It checks:

Was the witness itself re-entered?
Is the re-entry receipt still valid for this epoch or scope?
Does the manifest head match the immutable store?
Is the request fresh?
Does the request match the committed scope?
Is there a later revocation or superseding manifest?
Does the policy allow this operation?

If the ceremony is admissible, the access witness emits a storage access receipt.

The receipt does not need to reveal the underlying file, plaintext, human meaning, or full scope.

7. Open or write the artifact

The user’s local system uses the relevant key material, wrapped key, local secret, wallet authority, and witnessed receipt to open or write the artifact.

For a read:

verify manifest
verify re-entry receipt
verify access receipt
unseal artifact key if admissible
decrypt artifact locally

For a write:

generate new artifact key
encrypt new artifact
write immutable object
publish new manifest head
obtain or attach witness receipt

The witness should not receive plaintext.

8. Revoke future access

Revocation writes a new immutable event:

revocation_event:
  scope_commitment
  revoked_branch_or_policy
  effective_epoch
  previous_manifest_head
  witness_receipt
  signatures

Revocation means:

this loop may no longer close under the old authority

It does not mean:

all previously disclosed plaintext has disappeared

The protocol boundary is future authorized participation in this storage loop.

Witness boot cycle

A witness’s operating cycle is:

BOOT
  load local witness key material
  locate public immutable store
  locate relevant checkpoints and encrypted logs

RE-ENTRY REQUEST
  request re-entry from parent or peer witnesses
  commit to requested scope, checkpoint, and epoch

QUORUM RE-ENTRY
  receive bounded re-entry receipts or activation contributions
  publish or attach the re-entry receipt

STATE DERIVATION
  re-enter encrypted logs if permitted
  reconstruct admissibility state from immutable artifacts

ACCESS WITNESSING
  observe a bounded storage ceremony
  verify request, manifest, policy, and freshness
  emit access receipt or refusal receipt

PUBLISH / RETURN
  write receipt to immutable storage or return it to requester for publication

FORGET
  discard decrypted logs, derived secrets, and ephemeral request state

The witness does not own history.

It knows how to re-enter it.

Public and encrypted logs

The immutable store may hold both public and encrypted logs.

Public logs preserve:

receipt hashes
checkpoint hashes
manifest heads
revocation commitments
witness re-entry commitments
public signatures

Encrypted logs preserve:

private scope details
relationship context
human-readable policy
refusal reasons
operational diagnostics
private request context

A witness may access public logs directly.

To open its own private logs, a witness must pass through re-entry.

This prevents the witness from maintaining invisible private memory.

Resolution rules

A witness should not decide arbitrarily.

It should resolve current state according to published deterministic rules.

A conceptual resolution order:

1. Verify immutable log checkpoint lineage.
2. Reject invalid signatures or broken hash links.
3. Reject events outside the recognized scope.
4. Apply revocations before grants when conflict exists.
5. Apply the newest valid policy by recognized log order.
6. Reject stale manifest heads superseded by valid later heads.
7. Require valid witness re-entry for the access witness.
8. Require fresh challenge or liveness ceremony for active access.
9. Emit access, refusal, checkpoint, or indeterminate receipt.

These rules are part of the machine-readable consent approximation.

They do not exhaust human consent.

Refusal artifacts

A system that records only approvals creates invisible coercion.

Refusal must also be witnessable.

A re-entry witness may say:

admit
refuse
unavailable
indeterminate

An access witness may say:

observed
refused
indeterminate

A refusal artifact may reveal little publicly, but its existence matters. It prevents denial, silence, or administrative failure from disappearing into the system’s shadow.

A witness that refuses to witness should leave a bounded refusal artifact, or its silence should become detectable after a defined timeout.

The triangle cell

The smallest living witness cell contains three witnesses.

A is re-entered by B + C.
B is re-entered by A + C.
C is re-entered by A + B.

For any storage event, two witnesses re-enter the third, and the third witnesses the storage event.

A + B → C re-entry
C → storage access receipt

This cell is elegant but brittle.

It has no single-witness sovereignty, but it has availability and collusion risks.

A stronger production pattern might require larger cells:

2-of-3 for ordinary re-entry
3-of-5 for recovery
1 parent + 1 peer for lineage-sensitive re-entry
rotating quorum for high-stakes operations

Those are implementation choices, not settled requirements.

The conceptual primitive is role separation:

two witnesses for re-entry
one separate re-entered witness for access
all receipts to immutable storage

What this prevents

This pattern helps prevent:

silent witness operation
self-certified witness authority
private mutable witness databases
unobserved administrative access
stale witness authority
single-witness capture
secret log rewrites
unbounded witness memory
provider-as-sovereign drift

It does not eliminate trust.

It makes trust expire unless re-witnessed.

What this does not prevent

This pattern does not prevent:

colluding witnesses
coerced witnesses
rubber-stamp peer witnesses
metadata leakage
denial of service by quorum refusal
dead witness networks
genesis capture
bad cryptographic implementation
endpoint compromise
plaintext copying after access
legal compulsion
social pressure disguised as approval

Those remain first-class design problems.

Threat surfaces

Plaintext escape

Once plaintext leaves the protected boundary, the protocol cannot cryptographically revoke it.

The protocol governs future authorized access to protected artifacts. It does not govern human memory, screenshots, local exports, caches, or downstream unauthorized copies.

Witness cartel

If the only available witnesses form a closed group, witness re-entry can become priesthood.

Mitigations may include witness rotation, witness replacement, public refusal artifacts, larger quorum sets, delayed recovery, and the right to fork to a new witness cell.

Metadata leakage

Even encrypted content leaks through access metadata.

Witness receipts, re-entry requests, manifest updates, revocation timing, and refusal artifacts can reveal relationship structure.

The protocol should treat metadata as consent-relevant data.

Recovery capture

Recovery flows often become the weakest part of identity systems.

A consentful recovery process must preserve user agency while preventing social recovery from becoming social override.

False immutability

If the storage layer claims immutability but allows invisible deletion or mutation, the protocol loses its witnessable history.

Manifests and receipts should identify content by hash or equivalent verifiable reference.

Coercive transparency

A witness log can protect consent, but it can also collapse boundaries.

The system should prove what is necessary without turning every access into total surveillance.

Non-goals

This protocol is not:

a promise to erase already-seen plaintext
a production-ready encryption standard
a claim that TOTP is sufficient for consent or phishing resistance
a claim that BIP32 is the correct production derivation system
a digital rights management scheme
a way to control another person’s memory
a replacement for endpoint security
a replacement for backups
a reason to give the witness plaintext
a reason to let the witness become a sovereign
a claim that immutability is always ethically sufficient

The central claim is not “encrypt files better.”

The central claim is:

Consent is the condition under which this protected loop may assemble fresh authority for the next access.

That means consent is not merely a label stored beside an object. It is the operational gate that determines whether the system can close the next loop.

In a mature version of this protocol, every meaningful access asks:

Is this still the right authority?
Is this still the right person or agent?
Is this still the right scope?
Is this still the right artifact?
Is this still the right witness condition?
Was the witness itself re-entered?
Is this still the right time?
Is this still the right kind of use?

Only then does storage become consentful.

Protocol compression

Artifact: immutable
Store: public or encrypted, append-only
Lineage: scoped
Witness: re-entered
Access: witnessed
Authority: bounded
Revocation: future-facing
State: manifest/head/pointer
Consent: condition of next closure

Or shorter:

The file remembers.
The manifest bounds.
The witness re-enters.
The cell admits.
The key bridges.
Consent closes — or refuses — the next loop.

Research fit

This proposal fits a larger research frame:

consent as a stability property
revocation as re-keying shared reality
influence radius as the cost surface of consent updates
waste as the downstream signal of ignored refusal
witness as the catalyst that turns an attractor state into an artifact
witness re-entry as bounded continuity rather than unilateral authority

The storage-forward contribution is that these claims become operational in a concrete system. The question can be measured:

How expensive is revocation?
How far does a consent update propagate?
How much stale access survives?
How much witness data is necessary?
How often do witnesses refuse or fail re-entry?
How quickly can a system restore admissible state?
How much metadata is exposed per witnessed access?

A good implementation should reduce revocation cost without increasing violation persistence, witness capture, or coercive metadata exposure.

Open questions

Should witness re-entry release activation material, issue a signed receipt, or participate in threshold unsealing?
How short should a witness re-entry epoch be?
Should the access witness be randomly selected, rotated, or chosen by policy?
How large should witness cells be for different stakes?
How can refusal artifacts be public enough to prevent invisible coercion but private enough to avoid retaliation?
How much metadata can be blinded while preserving auditability?
What is the right recovery path if one witness dies, disappears, or is captured?
Can witness cells fork without causing permanent split-brain?
What is the minimal liveness ceremony that avoids user bypass?
What replaces TOTP-like paired codes in a hardened implementation?
What replaces BIP32-like derivation in a hardened implementation?
When should immutable ciphertext be sealed, quarantined, expired, or destroyed?
What is the smallest useful scope for child-key derivation or scoped authority?
How should consent state be represented so machines can enforce it without pretending to understand all human meaning?

Final formulation

A consentful immutable storage system does not delete the past.

It prevents this storage loop from lending fresh authority to a past artifact after consent has changed.

That is the full loop:

human intent
  → scoped wallet authority
  → local participation
  → witness-cell re-entry
  → separate access witness
  → witnessed admissibility
  → immutable artifact access
  → manifest update
  → future consent state

The artifact is history.

The manifest is the current boundary.

The witness cell is relational continuity.

The access witness is the moment access becomes legible.

The key is the consented bridge.

And revocation is the system’s ability to say:

This may have happened, but it does not get to keep happening through me.

Export notes

Suggested destination:

src/content/essays/consent-keyed-immutable-storage-loops.md

Suggested commands:

git add src/content/essays/consent-keyed-immutable-storage-loops.md
git commit -m "Revise Consent-Keyed Immutable Storage Loops witness model"
git push