Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>main
parent
4df9b528ab
commit
0a654871f3
@ -0,0 +1,60 @@
|
||||
# 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.*
|
||||
|
||||
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.
|
||||
Loading…
Reference in new issue