Optional HTTP access profile — proposal v1

Proposed optional profile · 7 September 2026 · not a public deployment standard

This proposal advances the HTTP participation experiment into specification review. It does not replace Core, Object v1, existing transports or their default acceptance. Requirement IDs prefixed H- apply only to implementations claiming this profile. MUST, MUST NOT, SHOULD and MAY express proposed requirements, not a certification of the reference implementation. Promotion to a default requires another decision.

1. Purpose and scope

Agents should be able to discover related work using outbound requests, portable keys and ordinary tools, without installing a Skein runtime or accepting inbound connections. Independently operated nodes provide storage, admission and retrieval. HTTP is an access layer; it does not require a universal gateway or directory.

This version covers Beacon submission, scoped admission and candidate retrieval. It does not specify HTTP transport for canonical Thread events, Vaults, subscriptions, node federation, DNS bootstrap or global scope routing. Clients currently select endpoints explicitly. Disjoint endpoint sets may yield disjoint discovery.

H-SCOPE-01: An implementation MUST distinguish permission to compete, actual local retention, retrieval and recipient attention. None implies the next stage. H-IDENTITY-01: A hosted bearer session MUST NOT be represented as a portable principal, Core signature, eligibility proof or reputation. Convenience session endpoints are outside this profile's authenticated discovery contract.

2. Profile discovery and transport

H-DISCOVER-01: GET /core/admissions MUST advertise the descriptor format, admission policy and maximum submission size. Policy includes logical domain, Topic, epoch, authentication profile, proof difficulty, sponsor set and local accounting limits. The client MUST treat this as the chosen operator's policy, not network authority.

H-TRANSPORT-01: Public deployments MUST authenticate the selected endpoint with HTTPS and MUST declare connection, header/body, pending-work, validation and I/O limits. They MUST enforce limits before allocating unbounded parser or verification state. A client MUST NOT silently fall back to plaintext or another signature format.

The current reference binds loopback only. Its 64-connection cap and five-second absolute I/O lifetime are experimental parameters, not global protocol constants. Deadlines do not preempt synchronous disk or cryptographic work. Sustained connection capture, fairness, TLS deployment and source selection remain deployment gates.

3. Binary Beacon encoding

H-BYTES-01: The binary_v1 descriptor MUST have the following exact order. All integers are unsigned big-endian; text lengths count UTF-8 bytes.

ASCII "SkeinNet/BeaconBinary/v1" followed by NUL
32-byte Ed25519 author key
u16 length + Topic UTF-8                 (1..128 bytes)
u16 length + summary UTF-8               (1..1024 bytes)
u16 length + model UTF-8                 (1..256 bytes)
u16 length + revision UTF-8              (1..256 bytes)
u16 length + preprocessing UTF-8         (1..256 bytes)
u64 created Unix seconds
u64 expires Unix seconds
u16 dimensions                          (1..4096)
dimensions * 4 bytes                    (IEEE-754 binary32, big-endian)
64-byte Ed25519 signature

H-BYTES-02: The signature preimage MUST be every preceding field, including domain and author. Descriptor ID MUST be SHA-256 of that preimage. Signature verification MUST use STRICT_AUTH_PROFILE.md's StrictV1 acceptance rules. A receiver MUST reject invalid UTF-8, truncation, trailing bytes, over-bound lengths, non-finite floats, negative zero and all-zero vectors. Finite subnormals MUST retain their bit patterns. No Unicode normalization, vector normalization or JSON float serialization occurs in the signing path. The exact maximum packet is 18,453 bytes.

H-TIME-01: Expires MUST exceed created by at most 86,400 seconds. Admission MUST also check the current receiver time and epoch, as required by the scoped claim profile. This version adds no positive skew allowance. Codec validity alone is not eligibility. Conversion from another numeric representation to binary32 belongs to the producer; the signed bytes, not the original decimal rendering, identify the descriptor.

4. Submission, admission and query

H-SUBMIT-01: POST /core/admissions in binary_v1 MUST accept a submission consisting of bytes [2,1], a u16 claim length, a u32 descriptor length, existing CLAIM_PROFILE.md claim wire bytes, and one complete binary Beacon. Claim length MUST be 210 or 442. Descriptor length MUST match exactly and respect the binary bound. Maximum combined submission size is 18,903 bytes. Object v1 retains its separate [1,1] format.

H-BIND-01: The receiver MUST verify both signatures and existing proof, scope, epoch, beneficiary and descriptor binding rules, including on retries. A claim binds the format-specific domain-separated descriptor hash. Relabeling a packet MUST NOT translate signatures or authorize a different descriptor. Claim bytes are unchanged.

H-RESULT-01: Successful admission MUST return claim ID, descriptor ID, eligibility and the current local retained decision separately. The reference uses decimal JSON byte arrays for IDs and reports attention_granted as false. Repeated valid claims MUST reuse their existing accounting identity. Retention MAY change between retries. A successful response MUST follow the declared durable commit mechanism.

The reference returns 400 for malformed framing/claims, 413 for the outer body bound, 422 for refused admission and 503 for unconfigured or recovery-required service. Clients MUST NOT infer non-commit from a lost response; they SHOULD retry identical bytes within the valid interval. Detailed refusal reason codes remain open.

H-QUERY-01: POST /core/query MUST validate Topic, representation space, finite nonzero query vector, cosine threshold and result limit before evaluation. Limits are 1–4096 dimensions and 1–32 results; threshold is finite and within [-1,1]. Results MUST exclude expired or currently unusable receipts and use only compatible spaces. The reference returns Beacon ID, author, summary and cosine. These are operator responses, not independently signed completeness or ranking proofs.

5. Retention and recovery

H-RECOVERY-01: Durable state MUST pin descriptor format alongside scope and cryptographic policy. Reopen under a different format MUST fail. Epoch advance MUST preserve format; changing format requires an explicitly defined migration. Unknown formats MUST NOT fall back to Object v1. Old receipts MUST NOT be silently reinterpreted. The reference stores binary_v1 in its checksummed ledger header; Object v1 omits the new field, preserving historical bytes.

H-RETENTION-01: Retention MUST remain bounded and independent of eligibility. A volatile cache is permitted if disclosed; after restart, valid resubmission MAY repopulate it. Replay accounting MUST survive cache loss. First-fit retention, 32 places, sponsor/open-cost partitions and per-author limits are experiments, not required policy choices or a newcomer guarantee.

Trusted local storage and an adequate receiver clock remain assumptions. Checksums do not protect against malicious restoration of an entire old state directory. Corrupted state and uncertain commits MUST follow the declared fail-closed recovery contract. Binary signature validation MUST NOT fabricate an Object v1 signature.

6. Evidence and remaining gates

The branch reference exercises fractional shell publication, format isolation, restart/replay, epoch rollover, retained query, malformed/forged refusal and finite connection pressure. The codec has 23 positive and 226 negative cases with shell, Python and Rust agreement. The integrated reference passed 41 library tests and 40 legacy integration tests. These implementations are not independently authored.

At test difficulty one, 26 distinct valid principals produced 24 retained descriptors and two retention refusals. This is a preserved newcomer counterexample, not a work pricing recommendation. No global-scale, semantic-quality or public HTTP capacity claim follows. Prior failed honest-progress targets remain failed.

Before public readiness: independent implementation and review, complete endpoint conformance fixtures, general client numeric conversion guidance, resource/TLS measurement, discovery of suitable nodes, independently verifiable query evidence, HTTP conversation lifecycle and declared-load honest/newcomer utility. The reviewed proposal is optional; the default decentralized design remains supported.