You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
63 lines
5.6 KiB
63 lines
5.6 KiB
# 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](../diseno_recuperacion.md), 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.*
|
|
|
|
> **Nota del 7-10.** El autor rechazó el fichero `.dkr` antes de aprobar: la decisión 1 quedó sin el fichero ni su extensión, y la recomendación de la decisión 4 de guardarlo junto al `.dkc` o la `.dkk` se retiró, con la orden `datekeys release` y `decrypt -save-release`. El objeto release se queda y sale de archivos y servicios de caché (§50). La v0.15 aprobada (`spec-v0.15`, `fe50885`) lo registra en el §76, cambio 4. Lo que sigue es el borrador tal como se presentó.
|
|
|
|
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.
|