From cbbdca0dd9edf7676019f164edf6b921b3824708 Mon Sep 17 00:00:00 2001 From: dev Date: Tue, 29 Sep 2026 20:47:22 +0200 Subject: [PATCH] Phase 3: steps 1 to 5 done in datekeys-ts (da0b39f) The plan table records each step with its commit; the handoff resumes at step 6 of the plan, the page decisions, which the author confirms, and drops the stale 0.1.0 question. Co-Authored-By: Claude Opus 5.5 --- HANDOFF.md | 26 ++++++++++++++++++-------- PLAN_fase3_escritura.md | 10 +++++----- README.md | 2 +- 3 files changed, 24 insertions(+), 14 deletions(-) diff --git a/HANDOFF.md b/HANDOFF.md index 224de39..59b3151 100644 --- a/HANDOFF.md +++ b/HANDOFF.md @@ -1,6 +1,6 @@ -# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 29 por la noche) +# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 29 por la noche, tras el paso 5 de la fase 3) -Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1), el 29 de madrugada tras cerrar la fase 2 (§2.2), el 29 a mediodía tras reorganizar el espacio de trabajo (§0) y el 29 por la noche tras implementar el formato 2 de la v0.9 en Go y en TypeScript y poner el tag `spec-v0.9` (§2.5). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude. +Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1), el 29 de madrugada tras cerrar la fase 2 (§2.2), el 29 a mediodía tras reorganizar el espacio de trabajo (§0) y el 29 por la noche tras implementar el formato 2 de la v0.9 en Go y en TypeScript, poner el tag `spec-v0.9` y escribir el writer TypeScript con su interoperabilidad con Go (§2.5). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude. --- @@ -89,13 +89,14 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9 ### 2.5 Sesiones del 29-09: v0.9 del spec y formato 2 en Go (retomar aquí) **Estado al parar (29-09 por la noche):** -- Pasos 1 a 5 hechos. El spec v0.9 está cerrado con el tag `spec-v0.9` (`7e2d83c`, en `main` de `datekeys-go`), y las dos implementaciones leen el formato 2: Go desde `f24a280`, que también lo escribe, y TypeScript desde `0118890`. Retomar por el paso 6, el plan de la fase 3. +- Pasos 1 a 5 hechos. El spec v0.9 está cerrado con el tag `spec-v0.9` (`7e2d83c`, en `main` de `datekeys-go`), y las dos implementaciones leen el formato 2: Go desde `f24a280`, que también lo escribe, y TypeScript desde `0118890`. +- Paso 6 en curso: la librería TypeScript ya escribe el formato 2 y Go abre lo que escribe (pasos 0 a 5 del plan de la fase 3, hasta `da0b39f`, subido). Retomar por el paso 6 del plan: las decisiones de la página, que confirma el autor. - Las 22 correcciones del repaso final ([spec_v0.9/review.md](spec_v0.9/review.md)) se aplicaron en `4a025d1`, más cuatro sitios que repetían los mismos problemas: las reglas 1 y 4 del §62.1 y los cambios 4 y 10 del §76. Los números de la corrección 1 se recalcularon con un Padmé en BigInt. - La corrección 2 la decidió el autor el 29-09: se suaviza el §56. - El lector MUST NOT presentar el contenido como válido antes de que termine el paso 17. - Un lector en streaming MUST NOT escribir el relleno y MUST señalar el error para que se descarte lo escrito. - Así siguen valiendo `Open(dst)` de Go y la salida en streaming de TypeScript. -- En este repo están [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md), el plan del writer TypeScript, y [REVISION_completitud_protocolo.md](REVISION_completitud_protocolo.md), la revisión del protocolo. El plan está en su v2, replanteado sobre la v0.9 y revisado; sus decisiones esperan la confirmación del autor. +- En este repo están [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md), el plan del writer TypeScript, y [REVISION_completitud_protocolo.md](REVISION_completitud_protocolo.md), la revisión del protocolo. El plan está en su v3: el autor confirmó sus 17 decisiones el 29-09. **Aprobación del 29-09.** El autor aprobó el texto de la v0.9 con las respuestas recomendadas a las preguntas abiertas: 1. L es un `bstr` de 8 bytes, no un `uint`. @@ -166,22 +167,31 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9 - autocomprobaciones; - recipients canónicos y no de orden bajo, como Go; - `SEALED_CONTROL_LEN` con la fórmula del §62.1 y comprobada. - Una revisión crítica con sondas no encontró nada bloqueante ni grave, y sus 12 correcciones menores están incorporadas. **Siguiente:** el autor confirma las 17 decisiones de su sección 2 (paso 0 del plan); después se implementa por pasos. + Una revisión crítica con sondas no encontró nada bloqueante ni grave, y sus 12 correcciones menores están incorporadas. + + Hecho el 29-09 en `datekeys-ts`, todo subido y con `npm run verify` en verde en cada paso: + - paso 0: el autor confirma las 17 decisiones con su recomendación, entre ellas cerrar `0.1.0` ya (D14), la fórmula del §62.1 comprobada con el sellado real (D3) y aceptar los puntos del twist, como Go (D6). El plan pasa a v3 (`b97dee2` en este repo); + - paso 1: `0.1.0` cerrada (`d577283`, tag `v0.1.0`) y `0.2.0-dev` abierta (`8c08c97`); + - paso 2 (`8838c7d`): `recipient.ts`, `random.ts` y `agefile.ts`, y las guardas nuevas; + - pasos 3 y 4 (`8473fdf`): `encrypt.ts` y `writer.ts`. Reproducen byte a byte las secciones deterministas de los siete fixtures del formato 2 de Go, escriben en streaming y abortan la salida ante cualquier fallo. El bucle de propiedades pasa con 500 semillas; + - paso 5 (`da0b39f`): Go abre con cada credencial las trece cápsulas de muestra que escribe TypeScript, y las reencodifica a los mismos bytes. Rechaza cuatro mezclas con el mismo código y paso, codifica igual 500 entradas aleatorias y da los mismos textos en 22 recipients y 21 opciones inválidas. Todo queda congelado en `src/lib/dkc/testing/capsule-vectors.json`. + + **Siguiente:** el paso 6 del plan, las decisiones de la página (sección 9): la ruta, las entradas, los avisos y sus textos, la salida y la privacidad. Las confirma el autor; después, el paso 7, la página. **Conclusiones de la conversación, sin decisión pendiente:** - El protocolo no contempla un sello de tiempo de creación (§5, §55.1). Si se quiere, lo recomendado es un sello RFC 3161 u OpenTimestamps sobre el SHA-256 del `.dkc` completo, guardado aparte. - Un fichero único `.dk` con `.dkc` y `.dkk` juntos no conviene: con `time_and_key` equivaldría a `time_only`. Ya se envía un solo fichero con `time_only` o con destinatarios `age1…`. -- `datekeys-ts` sigue en `0.1.0-dev`; decidir si se cierra `0.1.0`. +- `datekeys-ts` cerró `0.1.0` el 29-09 (`d577283`, tag `v0.1.0`), y la fase 3 va en `0.2.0-dev`. ### 2.3 Depende del autor - Crear `security@datekeys.com` y, si se quiere, un `security.txt` en la web. Después, actualizar `SECURITY.md`, que hoy dice `info@activething.com`. - Elegir la ruta pública del módulo Go (propuesta: `datekeys.com/go/datekeys`, en minúsculas) y el espejo público, que no puede ser GitHub (por ejemplo Codeberg). Publicar la página `go-import` en `datekeys.com`. Después: renombrar el módulo y poner el tag `v0.1.0` cuando `go get` funcione desde una máquina limpia. -- Decidir si `datekeys-ts` pasa de `0.1.0-dev` a `0.1.0`, ahora que la fase 2 está completa. +- Confirmar las decisiones de la página de la fase 3 (sección 9 del plan): la ruta, las entradas, los avisos y sus textos, la salida y la privacidad. ### 2.4 Más adelante -Fase 3 (writer TypeScript de cápsulas), Release API sobre la librería, traducción del spec al inglés y revisión externa antes de la v1.0. +Release API sobre la librería, traducción del spec al inglés y revisión externa antes de la v1.0. La fase 3 está en curso (§2.5, paso 6). --- diff --git a/PLAN_fase3_escritura.md b/PLAN_fase3_escritura.md index 8f08e9c..dffee27 100644 --- a/PLAN_fase3_escritura.md +++ b/PLAN_fase3_escritura.md @@ -556,11 +556,11 @@ Queda para que el autor decida en el paso 6: | Paso | Contenido | Hecho cuando | |---|---|---| | 0 | Confirmar las decisiones de la sección 2, y que no hace falta ninguna dependencia nueva (sección 3) | Hecho el 29-09-2026: todas confirmadas con su recomendación; el plan pasa a v3 | -| 1 | Precondición | `main` en verde, con `testdata` en `7e2d83c` (`spec-v0.9`): ya se cumple en `0118890`.
La decisión 14 está aplicada; si se cierra `0.1.0`, su commit y su tag van antes del paso 2 | -| 2 | Piezas de apoyo (sección 5) y guardas nuevas (decisión 13) | Derivación del recipient igual a la de `identityToRecipient` y a RFC 7748.
`parseX25519Recipient` y `checkX25519Recipient` rechazan los casos de la sección 8, punto 1, con los textos de Go.
`permute` pasa la prueba de uniformidad.
El hasher da lo mismo que Web Crypto.
`open.ts` usa `compareInstants` sin cambiar ningún test.
`tempfile.ts` parametrizado, con la apertura intacta.
Guardas nuevas en verde.
Módulos tocados al 100 % | -| 3 | `encrypt.ts` y `writer.ts` con entrada en memoria (sección 4) | La tabla de opciones inválidas da los textos y códigos esperados, sin escribir nada y con la salida abortada.
Las secciones deterministas de los siete fixtures de formato 2 salen byte a byte, y cada credencial abre su hueco (sección 8, punto 2).
Ida y vuelta con `open` para las dos políticas, de 1 a 16 credenciales y los dos códigos.
Claves portables nunca repetidas; caso `now + 1 h`.
Los dos módulos al 100 %, fijado como umbral | -| 4 | Streaming y salida (sección 6) | `Uint8Array`, `Blob` y `ReadableStream` dan el mismo contenido al abrir y las mismas longitudes, también con un trozo de entrada de varios MiB.
Nada se escribe antes del paso 17 del flujo.
Una salida o una fuente que fallan, una fuente de L ± 1 bytes y un `progress` que lanza dejan la salida abortada y nunca cerrada.
`capsule_digest` es el SHA-256 de lo escrito.
El bucle de propiedades pasa con 50 semillas, y con 500 a mano.
Las mezclas dan el código y el paso esperados.
Medida de rendimiento en Node, anotada en el README | -| 5 | Interoperabilidad TS → Go a nivel de cápsula (sección 8, punto 9) | Go inspecciona y abre todas las muestras con cada credencial, con el mismo SHA-256 del contenido y los mismos L, código y P.
Go recodifica PUBLIC_HEADER, CONTROL_CBOR y `.dkk` a los mismos bytes.
El diferencial de encoders no da ninguna diferencia.
Las mezclas dan el mismo código y paso en Go y en TypeScript.
Los veredictos de recipients y los textos de opciones coinciden, salvo los `TypeError` de la decisión 9.
Todo congelado en `capsule-vectors.json`.
README con la fila "Equivale en Go" de `encrypt.ts` (`capsule.Encrypt`, `accesskey.Encode`) | +| 1 | Precondición | `main` en verde, con `testdata` en `7e2d83c` (`spec-v0.9`): ya se cumple en `0118890`.
La decisión 14 está aplicada; si se cierra `0.1.0`, su commit y su tag van antes del paso 2.
Hecho el 29-09-2026: `0.1.0` cerrada en `d577283`, con el tag `v0.1.0`, y `0.2.0-dev` abierta en `8c08c97` | +| 2 | Piezas de apoyo (sección 5) y guardas nuevas (decisión 13) | Derivación del recipient igual a la de `identityToRecipient` y a RFC 7748.
`parseX25519Recipient` y `checkX25519Recipient` rechazan los casos de la sección 8, punto 1, con los textos de Go.
`permute` pasa la prueba de uniformidad.
El hasher da lo mismo que Web Crypto.
`open.ts` usa `compareInstants` sin cambiar ningún test.
`tempfile.ts` parametrizado, con la apertura intacta.
Guardas nuevas en verde.
Módulos tocados al 100 %.
Hecho el 29-09-2026 (`8838c7d`): `recipient.ts`, `random.ts` y `agefile.ts`, con los añadidos a `x25519.ts`, `digest.ts`, `datekey.ts` y `tempfile.ts`; los tres módulos nuevos, al 100 % y fijado como umbral | +| 3 | `encrypt.ts` y `writer.ts` con entrada en memoria (sección 4) | La tabla de opciones inválidas da los textos y códigos esperados, sin escribir nada y con la salida abortada.
Las secciones deterministas de los siete fixtures de formato 2 salen byte a byte, y cada credencial abre su hueco (sección 8, punto 2).
Ida y vuelta con `open` para las dos políticas, de 1 a 16 credenciales y los dos códigos.
Claves portables nunca repetidas; caso `now + 1 h`.
Los dos módulos al 100 %, fijado como umbral.
Hecho el 29-09-2026, junto con el paso 4 (`8473fdf`) | +| 4 | Streaming y salida (sección 6) | `Uint8Array`, `Blob` y `ReadableStream` dan el mismo contenido al abrir y las mismas longitudes, también con un trozo de entrada de varios MiB.
Nada se escribe antes del paso 17 del flujo.
Una salida o una fuente que fallan, una fuente de L ± 1 bytes y un `progress` que lanza dejan la salida abortada y nunca cerrada.
`capsule_digest` es el SHA-256 de lo escrito.
El bucle de propiedades pasa con 50 semillas, y con 500 a mano.
Las mezclas dan el código y el paso esperados.
Medida de rendimiento en Node, anotada en el README.
Hecho el 29-09-2026 (`8473fdf`): 500 semillas del bucle de propiedades en 203 s; en Node 24.9, unos 120 ms por cápsula `time_only` y 50 MiB/s desde un `Blob` | +| 5 | Interoperabilidad TS → Go a nivel de cápsula (sección 8, punto 9) | Go inspecciona y abre todas las muestras con cada credencial, con el mismo SHA-256 del contenido y los mismos L, código y P.
Go recodifica PUBLIC_HEADER, CONTROL_CBOR y `.dkk` a los mismos bytes.
El diferencial de encoders no da ninguna diferencia.
Las mezclas dan el mismo código y paso en Go y en TypeScript.
Los veredictos de recipients y los textos de opciones coinciden, salvo los `TypeError` de la decisión 9.
Todo congelado en `capsule-vectors.json`.
README con la fila "Equivale en Go" de `encrypt.ts` (`capsule.Encrypt`, `accesskey.Encode`).
Hecho el 29-09-2026 (`da0b39f`): trece muestras, cuatro mezclas, 500 entradas de los codificadores, 22 recipients y 21 opciones inválidas, sin ninguna diferencia con Go | | 6 | Decisiones de la página (sección 9) | el autor confirma la ruta, las entradas, los avisos y sus textos, la salida y la privacidad | | 7 | Página | En la compilación de producción, un fichero propio se cifra a `.dkc` y `.dkk` sin ninguna petición fuera del origen, y el informe de los pasos 1 a 8 del `.dkc` escrito pasa, con formato 2.
Una cápsula creada para dentro de dos o tres minutos se abre después en `/inspect` con el release pegado, y a mano con `datekeys decrypt` de Go, con red y con su `.dkk`.
El aviso de §53 aparece antes de cifrar, solo pasado el umbral.
Cancelar a mitad no deja fichero temporal.
Sin OPFS, la escritura va a memoria.
375 px de ancho.
`check-build` generalizado, en verde.
Tamaño del bundle de la página anotado.
Módulos nuevos al 100 %.
Revisión adversarial con cada hallazgo contrastado | diff --git a/README.md b/README.md index 2954783..191fa14 100644 --- a/README.md +++ b/README.md @@ -42,6 +42,6 @@ Para retomar el trabajo, lee [HANDOFF.md](HANDOFF.md): el estado de cada repo, l | [PLAN_libreria_go.md](PLAN_libreria_go.md) | Plan de la librería Go, hitos M0 a M5 (hecho) | | [PLAN_codec_cbor_y_pagina_svelte.md](PLAN_codec_cbor_y_pagina_svelte.md) | v2: codec CBOR propio en Go y TypeScript, librería TypeScript y página `/inspect` (hecho) | | [PLAN_fase2_ibe_noble2.md](PLAN_fase2_ibe_noble2.md) | v2: fase 2, abrir cápsulas en el navegador (hecho) | -| [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md) | Fase 3, writer TypeScript del formato 2 (v0.9). v2, revisada; sus decisiones esperan la confirmación del autor | +| [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md) | Fase 3, writer TypeScript del formato 2 (v0.9). v3, con las decisiones confirmadas; pasos 0 a 5 hechos (la librería y su interoperabilidad con Go); siguen las decisiones de la página y la página | | [REVISION_completitud_protocolo.md](REVISION_completitud_protocolo.md) | Qué le falta al protocolo antes de la v1.0 | | [spec_v0.9/](spec_v0.9/README.md) | Papeles de trabajo del borrador v0.9: diseño, revisiones y correcciones pendientes |