# Cryptographic redesign from v0.5 to v0.6

Canonical page: https://capsules.run/research/v0.5-to-v0.6-cryptographic-redesign/

Why the v0.6 envelope and chain look the way they do: each v0.5 footgun, the v0.6 replacement, and the second-implementation interop bomb each one would have caused.

## Why this redesign exists

The v0.5 format was a working JavaScript reference implementation. It round-tripped the canonical demos, signed the envelope, walked the chain, and decrypted the inner content. What it did not survive was the attempt to make the document, rather than the JavaScript code, the full interoperability contract.

v0.6 is the defensive redesign. Its goal is narrow: remove the interop bombs a second implementer is likely to hit before they hit them. v0.6 capsules are not backward-compatible with v0.5 capsules at the signing or chain layer.

## Main changes

1. Signature input is raw bytes, not a hex string. Ed25519 signs bytes; any ambiguity about the bytes being signed breaks interoperability.
2. The signing payload is the full canonical envelope minus signers, not a derived signing hash. The envelope itself becomes the commitment.
3. Signatures use domain separation per role so a signature made for one role cannot be replayed as another role.
4. Chain hashing uses raw bytes everywhere. Hex strings are representations, not hash inputs.
5. Capsule identity is bound to a key. v0.5 identity was too easy to treat as globally meaningful without enough commitment to the originator.
6. The cipher enum is fail-closed. v0.6 drops advertised cipher modes that no compliant implementation can open.

## What v0.6 does not fix

v0.6 closes integrity gaps. It does not close all trust gaps.

The `signed_at` timestamp is whatever the signer wrote at seal time. External time anchoring is a v0.7+ topic. The envelope proves that a key signed a canonical envelope, not that the key belongs to a specific real-world person or organization. If a private key is compromised, an attacker holding that key can produce capsules that verify.

## Test vectors are the contract

Under v0.5, the JavaScript reference implementation was effectively the spec. Under v0.6, the spec is the document plus signed test vectors. A second implementation is compliant when it round-trips those vectors bit-identically: same canonical bytes, same hashes, same signatures.

That line matters because it turns Capsule into a protocol rather than a single implementation. Future v0.7+ changes should follow the same pattern: ship the change, publish the vectors, get parity from at least one second implementation, then lock.

## Where this leaves the format

The reference JavaScript SDK ships against v0.6 with signed test vectors. Python parity work, a Rust verifier, and additional implementations are the practical route toward v1.0. The goal of v0.6 was to publish the format that should not need another break of this kind.

Specification: /protocol/v0.6/