datekeys-doc/spec_v0.15/decisiones.md

Borrador v0.15: decisiones para el autor

7 de octubre de 2026. El borrador está en la rama v0.15 de datekeys-go (b7402bd), en spec/DateKeys_Protocol_Specification_v0.15.md. Es la recuperación a largo plazo del diseño, con la opción A y las ocho recomendaciones que aprobaste el 6-10. Lo hizo un agente Opus; la sesión revisó el paso 9.c en el código. scripts/check.sh pasa entero, con un script nuevo que abre dos fixtures siguiendo solo el anexo.

Si apruebas lo que sigue tal como está, basta con decir «apruebo el borrador». Al aprobarlo se cierra como la v0.14 y se lleva a TypeScript, a Dart y al paquete de la revisión externa.

Lo que hace el borrador

1. El objeto de release y el fichero .dkr (§20, §47, §47.1 nueva, CDDL). Es un CBOR de 111 bytes: {0: "datekeys-release", 1: 1, 2: chain_hash, 3: ronda, 4: firma}. No lleva firma propia ni la marca de «verificado»: se comprueba contra el perfil fijado. Los lectores siguen aceptando el JSON de drand como entrada, pero un escritor nunca lo guarda.

2. La cadena en el paso 10 (§51, §63). Primero las capas del objeto, después chain_hash (ERR_PROFILE_MISMATCH), la ronda y la firma. No hay códigos de error nuevos.

3. El paso 9.c, opción B (§49, §63). El reloj local solo cuenta antes de pedir a la red. Un release que el lector ya tiene, pegado, de un fichero o de un archivo local, no se compara con el reloj, y el lector MAY avisar de que el reloj va atrasado.

4. La recuperación a largo plazo (§50, §53, §62.1 reglas 26 a 28):

   • el .dkr junto al .dkc es el camino principal, y también junto a una .dkk con localizador;
   • el archivo de releases es un formato informativo, sin prometer dónde se aloja;
   • el SDK SHOULD avisar al sellar, guardar el anexo y guardar el .dkr pasada la fecha.

5. La Release API (§45): su respuesta es el objeto de release; la forma HTTP es informativa.

6. El §74: salen los dos puntos de trabajo futuro que esto cubre, y entran la extensión datekeys.release de la .dkk y un archivo publicado.

7. El anexo de recuperación (§79 nueva, informativa, después del §78 para no renumerar el §77). Explica cómo abrir una cápsula time_only y una time_and_key sin el software de DateKeys:

   • los parámetros de Quicknet;
   • la trama;
   • la verificación del release;
   • el stanza tlock;
   • cómo abrir un fichero age desde su file key;
   • las capas X25519 con age -d;
   • el contenido de cada formato.

   scripts/recovery_check.sh lo demuestra con código que no importa nada de DateKeys, ni tlock ni drand.

Lo que el agente decidió distinto del diseño, para que lo apruebes o no

8. Un límite de tamaño del objeto: de 1 a 1024 bytes, con ERR_NON_CANONICAL_CBOR. Así el código de error no depende de cuánto lea un lector. La firma, de 1 a 96 bytes en el CDDL; otra longitud dentro de ese rango da ERR_RELEASE_INVALID.

   • Recomendación: aprobar.

9. Un JSON de drand mal formado da ERR_RELEASE_INVALID en el paso 10. Solo es una entrada de quien llama y nunca se escribe.

   • Recomendación: aprobar.

10. Los fallos del archivo de releases dan ERR_RELEASE_UNAVAILABLE en el paso 9. Una ronda que el archivo no tiene o no cubre, de otra cadena, o con otra longitud. Una ronda a ceros cuenta como ausente, no como firma que no verifica.

    • Recomendación: aprobar. El formato del archivo es informativo y no tiene códigos propios.

11. Lo que no hace la CLI de Go:

    • la opción de pedir a la red antes de la fecha aunque el reloj diga que no ha llegado, que el spec deja como MAY;
    • guardar el anexo junto a las cápsulas y avisar del release al sellar, que son SHOULD del SDK.

    Lo demás sí: decrypt -release FICHERO, decrypt -save-release y la orden nueva datekeys release, que pide, verifica y guarda el .dkr.

    • Recomendación: aprobar. Los SHOULD del SDK van con las recomendaciones de la v0.14 en los clientes, que siguen pendientes.

Lo que cambia en los vectores

• vectors/release.json, nuevo: 36 objetos, 12 JSON de drand y 7 consultas a un archivo, cada uno con su resultado y el texto de Go.

• releases/, nuevo: los .dkr de las rondas 1000, 1001, 1004 y 2000, y un archivo de las rondas 1000 a 1004 con la 1002 y la 1003 a ceros.

• mutations.json:

  • cada caso dice ahora si su release está en la mano (supplied) o viene de la red (network);
  • «la ronda aún no ha llegado» pasa a abrir con un release en la mano, por la opción B;
  • hay cuatro casos nuevos: ese mismo caso desde la red, un release de otra ronda desde la red, y dos objetos de otra cadena.

  Son 222 casos, 178 del §64. Ningún otro cambia de resultado.

Al aprobar

• Como la v0.14: la fecha de la cabecera, SpecVersion 0.15, el SHA-256, el tag spec-v0.15 y main.
• TypeScript y Dart siguen el borrador: el objeto, la fuente en la mano, el paso 9.c, los vectores nuevos y el campo source del corpus. La guarda de TypeScript exige una prueba para cada fichero nuevo de testdata.
• El paquete de la revisión externa se pone al día con los commits nuevos y con la recuperación ya resuelta.
• Sale una 0.4.0 de TypeScript.