The author approved specification v0.16 on 7 October 2026, tagged
spec-v0.16 at b6ff17a. Only the annex changes, with the SHA-256 of the
approved text, and the README of testdata; the README and the CHANGELOG
name the approved version.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@ -6,9 +6,9 @@ Cambios notables de la librería TypeScript y de la página. El proyecto usa ver
### El borrador de la especificación 0.16 (07-10-2026)
El borrador v0.16 de la rama `v0.16` de `datekeys-go`, en `3fd0e93`, aún sin aprobar: lo que encontró la revisión de Astra de la v0.15. No cambia ningún formato; cambian el veredicto de un sello sin `accuracy` y la lectura del JSON de drand (§76, «Cambios normativos de la v0.16»).
La v0.16 de `datekeys-go`, aprobada el 7 de octubre de 2026 con el tag `spec-v0.16` (`b6ff17a`): lo que encontró la revisión de Astra de la v0.15. No cambia ningún formato; cambian el veredicto de un sello sin `accuracy` y la lectura del JSON de drand (§76, «Cambios normativos de la v0.16»).
- `SPEC_VERSION` pasa a `0.16`. `testdata`, `wordlists` y `annex` se sincronizan con `3fd0e93` (`node scripts/sync-testdata.mjs sync --commit 3fd0e93`), que devuelve a `release.json` los escapes de sus casos `\u0072ound` y del par de sustitutos, que `4f78854` había perdido: el campo `spec` de cada fichero dice `0.16`; `vectors/security_cms.json` se hizo de nuevo, con 143 casos y `seal_reason`; `vectors/release.json` gana 26 casos del JSON de drand; `vectors/wordkey.json`, el texto del vector del anexo, también con sus marcas sueltas, y su llave; y llegan dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. El anexo de recuperación es el §79 del borrador v0.16, con la licencia de la especificación, CC BY-ND 4.0, en su título (`70d907b`) y la llave de palabras en 79.7.
- `SPEC_VERSION` pasa a `0.16`. `testdata`, `wordlists` y `annex` se sincronizan con `b6ff17a`, el commit del tag (`node scripts/sync-testdata.mjs sync --commit b6ff17a`), cuyo anexo lleva el SHA-256 de la versión aprobada; antes, `3fd0e93` devolvió a `release.json` los escapes de sus casos `\u0072ound` y del par de sustitutos, que `4f78854` había perdido: el campo `spec` de cada fichero dice `0.16`; `vectors/security_cms.json` se hizo de nuevo, con 143 casos y `seal_reason`; `vectors/release.json` gana 26 casos del JSON de drand; `vectors/wordkey.json`, el texto del vector del anexo, también con sus marcas sueltas, y su llave; y llegan dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. El anexo de recuperación es el §79 del borrador v0.16, con la licencia de la especificación, CC BY-ND 4.0, en su título (`70d907b`) y la llave de palabras en 79.7.
- **El sello sin `accuracy`** (§29.7, §29.11, como `7e3b810` de Go). Un sello válido es S4 solo si el token lleva `accuracy` y t más la precisión es anterior a `round_time`; si no, S5, con el primer motivo que se cumple: `late`, sellado después o demasiado cerca; `no accuracy, BTSP`, sin `accuracy` en un token de la política BTSP de ETSI EN 319 421 (0.4.0.2023.1.1), que la exige; o `no accuracy`. Una `accuracy` de 0 segundos, o vacía, es una precisión de 0 y vale. `cms.ts`: el token gana `hasAccuracy` y `policy`, y `tokenIsBTSP`. `securitycms.ts`: `SealReason`, `Detail.sealReason` y `SignerLine.reason`. `security.ts`: S5 ya no tiene texto fijo; `verdictLines` escribe «No acredita que se sellara antes de la fecha de apertura: ‹motivo›.», y la línea de un firmante de F6 cuyo sello no lo acredita, «sin acreditar que fuera antes de la fecha de apertura: ‹motivo›», con los textos de `sealReasonText`, los de Go byte a byte.
- **El escritor avisa** (§62.1, regla 19). `encryptFiles` devuelve en `Encrypted.security` los veredictos del área que escribió, como `Result.Security` de Go: un sello sin `accuracy` se escribe, y quien escribe ve su S5, o la línea de su firmante, con el motivo. `/create` no sella, así que no cambia.
- **El JSON de drand, estricto** (§47.1, como `b570338` de Go). `releaseobject.ts` cambia el lector que imitaba `encoding/json` por `parseDrandJSON`, como `ParseDrandJSON` de Go: JSON de RFC 8259 en UTF-8 válido cuyo valor es un objeto, ningún nombre repetido en ningún objeto, nombres comparados exactos tras decodificar sus escapes (`"round"` es `round`, y `ROUND` otro nombre), un sustituto escapado sin su pareja es JSON mal formado, `round` es un número sin signo, fracción ni exponente de 1 a 2⁵³ − 1, `signature` y `randomness` son cadenas, y `randomness`, si viene, aunque sea vacía, es el SHA-256 de la firma. Los textos de error no cambian. Como la ronda ya no pasa de 2⁵³ − 1, `ParsedRelease` es un `Release`, sin `bigint`. `drand.ts` lee las respuestas de los relays con `parseDrandJSON`, como el cliente de Go, y `release-input.ts`, lo pegado, con `strictJSON` y `jsonRound`, para que la página no lea otra ronda que el paso 10.
@ -21,12 +21,12 @@ Hay tres números de versión, cada uno con su significado, como en la referenci
| Versión | Dónde | Cambia cuando |
|---|---|---|
| Formato | Dentro de los objetos: el formato de la cápsula, el `VERSION` del prelude de DKC1, 1, 2 o 3 al leer, que fija también la versión de schema de CONTROL_CBOR; y 1 en la trama DKK1 y en el schema de los demás objetos | Cambia el formato. Un lector rechaza una versión que no conoce (§22, §70) |
| Especificación | `SPEC_VERSION` de `src/lib/dkc/version.ts`, hoy `0.16`: el borrador v0.16 de la rama `v0.16` de `datekeys-go`, aún sin aprobar, en `3fd0e93`. `testdata` está en ese commit, y todos sus ficheros dicen `0.16` | Cambia el texto normativo |
| Especificación | `SPEC_VERSION` de `src/lib/dkc/version.ts`, hoy `0.16`: la v0.16 de `datekeys-go`, aprobada el 7 de octubre de 2026 con el tag `spec-v0.16`, en `b6ff17a`. `testdata` está en ese commit, y todos sus ficheros dicen `0.16` | Cambia el texto normativo |
| Librería | `VERSION` de `src/lib/dkc/version.ts`, igual al campo `version` de `package.json` | Cambia la API o el comportamiento. Versionado semántico, sin promesa de estabilidad antes de 1.0.0 |
`version.test.ts` comprueba que `VERSION` coincide con `package.json` y con su lockfile, y que `SPEC_VERSION` es la versión que nombran los vectores y fixtures compartidos; `vectors.test.ts` exige esa versión a cada fichero. El pie de la página muestra las dos.
La versión en desarrollo es `0.5.0-dev`, que sigue el borrador v0.16: el sello sin `accuracy` no prueba nada antes de la fecha de apertura, y el JSON de drand se lee estricto. La última publicada es la `0.4.0`, del 7 de octubre de 2026, con el tag `v0.4.0`, que cubre:
La versión en desarrollo es `0.5.0-dev`, que sigue la v0.16: el sello sin `accuracy` no prueba nada antes de la fecha de apertura, y el JSON de drand se lee estricto. La última publicada es la `0.4.0`, del 7 de octubre de 2026, con el tag `v0.4.0`, que cubre:
- la especificación 0.15 (el tag `spec-v0.15` de `datekeys-go`): lee los formatos de cápsula 1 a 3 y escribe el 3, y el 2 solo como generador de vectores (§62.1, regla 1);
- el objeto release y el release en la mano (§47.1, §49, §50, §63 pasos 9.c y 10): lee el objeto release y el JSON de drand con los textos de Go, busca la ronda en un archivo de releases local y abre con un release en la mano aunque el reloj vaya atrasado; `/inspect` acepta el release pegado o en un fichero;
- la firma de autor de `alg` 1, con las claves `dkauthor1…`, y la de `alg` 2 con certificados, y el sello RFC 3161: las evalúa al abrir con los veredictos de Go y las escribe con los enganches del escritor;
@ -475,7 +475,7 @@ Comprueba que los ficheros coinciden con `SOURCE.json`, sin faltantes ni sobrant
`.gitattributes` marca `testdata/**` y `wordlists/**` como binarios para que git no altere ningún byte.
Copia actual: la de `testdata/SOURCE.json`, `datekeys-go` en `3fd0e93`, el borrador v0.16 de la rama `v0.16`, que se sincroniza con `node scripts/sync-testdata.mjs sync --commit 3fd0e93`. Del mismo commit vienen `wordlists/` y `annex/`, el anexo de recuperación, que es ya el §79 del borrador v0.16, con la licencia CC BY-ND 4.0 de la especificación en su título y la llave de palabras en 79.7. Sobre el `testdata` de `spec-v0.15` (`fe50885`), el de la v0.16 cambia el campo `spec` de cada fichero a `0.16`, hace de nuevo `vectors/security_cms.json`, con 143 casos y `seal_reason`, añade a `vectors/release.json` los 26 casos de la lectura estricta del JSON de drand y a `vectors/wordkey.json` el vector del anexo, y trae dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. `wordkey/lists` trae la lista inglesa de la EFF y la española; la página solo publica la española.
Copia actual: la de `testdata/SOURCE.json`, `datekeys-go` en `b6ff17a`, el commit del tag `spec-v0.16`, que se sincroniza con `node scripts/sync-testdata.mjs sync --commit b6ff17a`. Del mismo commit vienen `wordlists/` y `annex/`, el anexo de recuperación, que es ya el §79 de la v0.16, con la licencia CC BY-ND 4.0 de la especificación en su título y la llave de palabras en 79.7. Sobre el `testdata` de `spec-v0.15` (`fe50885`), el de la v0.16 cambia el campo `spec` de cada fichero a `0.16`, hace de nuevo `vectors/security_cms.json`, con 143 casos y `seal_reason`, añade a `vectors/release.json` los 26 casos de la lectura estricta del JSON de drand y a `vectors/wordkey.json` el vector del anexo, y trae dos fixtures, `format3_time_and_key_words` y `format3_full_chunk`. `wordkey/lists` trae la lista inglesa de la EFF y la española; la página solo publica la española.
# Cómo abrir una cápsula DateKeys sin software de DateKeys
Este texto acompaña a una cápsula del tiempo de DateKeys, un fichero `.dkc`: dice cómo abrirla, llegada su fecha, sin ningún software de DateKeys, por si ya no existe. Es el anexo informativo §79 de la especificación del protocolo DateKeys v0.16, cuyo texto tiene el SHA-256 a3cbdc6ef99aeb3ec77e40c4ce838f6f5b8950af6191383e4033761d2ca1df80. Es el mismo para toda cápsula: no lleva ningún dato de esta. Su licencia es CC BY-ND 4.0, Atribución-SinDerivadas 4.0 Internacional (https://creativecommons.org/licenses/by-nd/4.0/deed.es): se puede copiar y compartir sin cambios, citando su origen.
Este texto acompaña a una cápsula del tiempo de DateKeys, un fichero `.dkc`: dice cómo abrirla, llegada su fecha, sin ningún software de DateKeys, por si ya no existe. Es el anexo informativo §79 de la especificación del protocolo DateKeys v0.16, cuyo texto tiene el SHA-256 807d4fe85ac09ad6f97abc75ab3e2156bb2f3fb0dc589777f4420627fad545e1. Es el mismo para toda cápsula: no lleva ningún dato de esta. Su licencia es CC BY-ND 4.0, Atribución-SinDerivadas 4.0 Internacional (https://creativecommons.org/licenses/by-nd/4.0/deed.es): se puede copiar y compartir sin cambios, citando su origen.
## 79. Anexo informativo: recuperación sin software DateKeys
