# Q1039 — Asynchronous Sneakernet Protocol Layer

- Q number: Q1039
- Primary URI: https://4p-engine.com/q/Q1039
- Current host route: https://mcbcore.net/q/Q1039
- Reserved subdomain alias: https://q1039.4p-engine.com/
- Record origin: Editorial synthesis, not a verbatim authored passage; based on Q1000, Q1007, Q1035, Q1037.

A source-labeled account of the implemented bounded browser workflow for offline work files and clock-independent reconciliation.

> An admin browser workflow carries existing signed, bounded work files between disconnected sites; confidential files use recipient-bound encryption, while public plaintext imports are governed by operator policy and content-addressed prerequisites can express causal order without wall-clock time.

The admin browser workflow exports an existing bounded signed work envelope for offline transfer and imports it on a configured, running node without a live peer. Independent jobs need no shared calendar or global counter. A causal prerequisite can name the content digest of a required manifest: if a child arrives first, it remains pending until the prerequisite is accepted.
The current reconciler verifies signed manifests and receipts, content-digest dependencies, task-specific result validity, and resource limits. The live task validator accepts the bounded parity-check-v1/parity-result-v1 contract; the service does not execute arbitrary submitted payloads. An enabled node durably commits accepted work and signed replay results to its PostgreSQL ledger. It does not coordinate a shared ledger across disconnected authorities or settle money. A signature identifies the configured signing key; it does not establish the truth of a result or show that a worker performed the computation. A digest identifies content but does not prove it correct. The MCB parity function (-1)^n is not a clock, global sequence, authentication primitive, or proof of execution.
Confidential portable files require recipient-bound HPKE encryption; eligible passphrase-encrypted public or legacy files remain importable for compatibility. Browser decryption does not bypass the receiving operator's plaintext task-type policy, and undeclared legacy files still require explicit opt-in. Public work files may be plaintext and readable by carriers. The file wrapper creates no signatures; the receiving node performs its configured signature, integrity, replay, dependency, and result checks. Accepted work and its replay result are durably committed within that node's PostgreSQL ledger, not across disconnected authorities.
The supplied Google AI draft also proposes split payloads. Splitting data does not by itself provide authentication, tamper detection, or forensic invisibility. Disconnected nodes may process the same job, so at-most-once acceptance in one durable authoritative ledger cannot be restated as exactly-once execution across partitions.
Recipient or passphrase encryption protects a portable file before it is opened. Public plaintext files are readable by their carriers. None of these file protections encrypts later mesh packets, queued database records, the receiving node after decryption, or a relay's view; these are separate confidentiality boundaries.

## Two-way derivation from Logic and its use

**Status:** editorial_derivation proof sketch (conditional_concept), distinct from authored source. Logic has its own evidence in reflexive demonstration: any denial, confirmation, observation, or counterexample presupposes identity and valid relation to count as evidence. Logic therefore grounds evidence rather than receiving authority from it. Empirical and documentary evidence can establish contingent instances and test applications, but cannot create, overrule, or exhaust Logic.

### From Logic to this concept

- **Bridge premise:** Given signed, schema-bounded manifests, content-addressed prerequisites, an explicit task validator, and one authoritative ledger, work bundles can be reconciled without a common clock.
- **Consequence:** Independent jobs need no global sequence; declared prerequisites form a causal relation, missing prerequisites remain pending, and the ledger can make acceptance idempotent within its own authority.
- **Proof limit:** A signature does not prove execution or correctness, a digest does not validate its contents, and disconnected authorities can duplicate work; MCB parity supplies none of those guarantees.

### From this concept back to Logic

- **Witness:** Deliver a dependent bundle before its prerequisite, then import the prerequisite and retry; restart the destination and replay the same message; race distinct messages carrying one receipt and verify one acceptance; submit a different valid result for the same manifest.
- **Disclosure:** Identifying a manifest across media, recognizing its prerequisite, and distinguishing replay from conflict require stable identity and valid relations, so clockless reconciliation remains governed by Logic.
- **Proof limit:** These checks establish durable acceptance and replay within one PostgreSQL-backed node across tested restarts and concurrent delivery; they do not establish exactly-once execution across disconnected nodes, correctness outside the declared parity validator, confidentiality, or settlement.

### Intelligence procedure

- **Human:** Check manifest authority, worker signature, dependency digests, resource bounds, result digest, and task-specific correctness separately; label missing prerequisites and conflicts instead of inferring order from arrival time.
- **Machine:** Canonicalize bounded JSON; verify allowlisted Ed25519 signers; check manifest-receipt binding, result digest, resource bounds, and task validator; atomically persist job/attempt acceptance with the destination replay result; keep any future settlement separately authorized and idempotent.

### Language and vocabulary procedure

- **Contrast:** A causal prerequisite names required content; a timestamp reports a clock reading; a signature authenticates a signer; a result validator checks task-specific correctness.
- **Usage rule:** Teach “clock-independent” only for independent jobs and explicit causal links; keep parity, cryptographic integrity, execution evidence, and ledger uniqueness as separate terms.
- **Example:** “The child bundle is pending because its parent digest is absent” states causal status without claiming that the child happened later in wall-clock time.

## Semantic meaning frame

- **Role:** bounded offline work-file transport and clock-independent reconciliation
- **Essence:** An admin browser workflow exports and imports bounded signed work files for disconnected handoffs; content-addressed dependencies express causal prerequisites without a shared clock or global counter.
- **Logos relation:** Logos requires causal identity and validated relations to govern acceptance: parity is a computational invariant, while signatures, task-specific validation, and an authoritative ledger perform distinct authentication, correctness, and idempotency duties.
- **Retrieval aliases:** Asynchronous Sneakernet Protocol Layer · clockless reconciliation · time-agnostic state matrix · offline work envelope · physical work bundle · causal manifest dependency
- **Evidence modes:** out-of-order dependency tests · replay and conflicting-result tests · transactional restart and concurrent-delivery checks · signature and key-policy checks · task-specific result validation · media-import limits and partition recovery

### Distinctions

- causal dependency is not wall-clock order
- a digest is not proof of execution
- a signature identifies a signer rather than truth
- parity is not authentication or a global sequence
- at-most-once ledger acceptance is not exactly-once offline execution
- confidentiality is not invisibility

## Coherence criterion

Offline reconciliation must preserve signed intent, validate task-specific results, express causal prerequisites independently of clocks, make replays and conflicts explicit, and state the limits of one ledger across disconnected authorities.

## Evidence boundary

This editorial synthesis records Google AI-generated sneaker-net proposals and the bounded reference workflow. It is not a verbatim authored passage; the verifier must inspect the source material and implementation evidence directly. The admin browser handles recipient-encrypted confidential files, passphrase-encrypted files for compatibility, and public plaintext files subject to receiving-operator task policy; it imports already-signed bundles into a configured node. The receiving node has a durable per-node PostgreSQL acceptance/replay ledger and validates the currently supported bounded parity task result; there is no arbitrary execution sandbox, distributed consensus, or economic settlement service. Encryption ends at the file/decryption boundary and does not conceal deliberately public plaintext or protect subsequent mesh traffic and stored records.

## Properties

- **recordOrigin:** Editorial synthesis of Google AI proposal material and a scoped reference design; not verbatim Hunter authorship.
- **sourceDocument:** Supplied three-record Google AI-generated draft material, Record Two; proposal text preserved for study, not independent implementation evidence.
- **supportingSourceDocuments:** Google AI-generated notes on micro-tokenomics and mesh-transit concepts were also supplied for study; they remain proposal material rather than implementation evidence.
- **designStatus:** A bounded admin browser workflow exports and imports existing signed envelopes into a durable per-node PostgreSQL ledger; confidential files use recipient-bound HPKE, passphrase-encrypted files remain compatible, and public plaintext imports follow receiving-operator task policy.
- **parityBoundary:** MCB parity is a computational invariant; it is not wall-clock time, global order, authentication, integrity proof, or proof that work was executed.
- **replayBoundary:** Disconnected execution may duplicate work; at-most-once acceptance requires one authoritative durable ledger and does not guarantee exactly-once execution across partitions.
- **confidentialityBoundary:** Confidential portable files use RFC 9180 HPKE (DHKEM(X25519, HKDF-SHA-256), HKDF-SHA-256, AES-256-GCM); eligible passphrase-encrypted public or legacy files using PBKDF2-SHA-256 and AES-256-GCM remain compatible, subject to the same plaintext task policy and explicit legacy opt-in. The encrypted HPKE envelope omits node ID, work ID, and bundle body, but its carrier can observe the recipient-key fingerprint and approximate file size. Public plaintext is readable. Decrypted work, mesh traffic, and queued database records are not protected end to end.

## Linked Q items

- [Q1000 — Q-Number Data and Metadata System](https://mcbcore.net/q/Q1000)
- [Q1007 — 4P Validator](https://mcbcore.net/q/Q1007)
- [Q1035 — UVMC](https://mcbcore.net/q/Q1035)
- [Q1037 — OASIS Operating Blueprint](https://mcbcore.net/q/Q1037)
- [Q1038 — P2P Edge Mesh Layer](https://mcbcore.net/q/Q1038)
- [Q1040 — Unified 4P-MCB Cybernet Ecosystem](https://mcbcore.net/q/Q1040)

## Related Wikidata concept items

These are typed external concept links for discovery and comparison. They are not sameAs assertions, endorsements, or substitutes for the first-party source and evidence.