8.1 KiB

Raw Blame History

Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 28)

Estado al parar la sesión del 26 por el límite semanal de uso, actualizado el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.

1. Repositorios

Los dos repos están en el Gitea privado g.activething.com (solo LAN, certificado autofirmado para git.activething.com; git funciona, curl necesita -k). Ese servidor no es del autor: no se proponen cambios en él. La integración continua es el gate local.

Repo	Rama	Commit	Estado
`datekeys-go` (`go/DateKeys`)	`main`	`3e4755e`	Spec v0.8.2 cerrada, con el tag anotado `spec-v0.8.2` en `9ac9cd9`. Después, `datekeys.SpecVersion`, `datekeys.Version()` y `datekeys version`, sin cambios en `testdata`.
	`v0.8.2`	`9ac9cd9`	El commit del tag; ya no hace falta.
`App` (`go/DateKeys-App`)	`main`	`a89bee5`	Versión `0.1.0-dev`, que implementa el spec 0.8.2 (`VERSION` y `SPEC_VERSION`, también en el pie de la página). Librería TypeScript con la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18), en memoria o desde un `Blob` hacia un stream de salida, como un fichero OPFS; página `/inspect`; contraste BLS. `testdata` sincronizado a `9ac9cd9`. Fase 2, pasos 2 a 5b hechos. Los 65 casos del corpus pasan por `open` con el código y el paso de Go. 2 560 tests, ninguno saltado; `npm run verify` en verde.
`AppOld` (solo local)	`master`	`4d2b0a1`	Prototipo antiguo. No se toca.

Verificación ya hecha sobre datekeys-go:

fuzzing de 30 min en cada uno de los 15 objetivos sobre 3820066, limpio;
diferencial Go/TypeScript de 407 196 entradas contra f6f2e9f, con cero diferencias, textos de error incluidos;
scripts/check.sh 60s sobre 9ac9cd9, el commit del tag, limpio (28-09);
govulncheck no encuentra nada alcanzable. Avisa, sin llamada alcanzable, de dos problemas:
- GO-2026-6443, en google.golang.org/grpc 1.84.0, arreglado solo en una versión -dev. Hay que subir grpc cuando salga la 1.85.0.
- GO-2026-5932, en golang.org/x/crypto/openpgp, sin arreglo. No lo importamos.

2. Qué queda, en orden

2.1 Hecho el 28-09: cierre de la v0.8.2

Los 9 retoques de la 2.ª revisión están en 9ac9cd9, un solo commit sobre c57ed48 que absorbe el WIP 69a3342. La rama WIP está borrada.
§76 los recoge como correcciones 4 a 6:
- un encoder MUST NOT escribir una extensión fuera de su registro;
- §17 y §51 dan los códigos del paso 10 solo para un release suministrado directamente;
- en el paso 9, cualquier fallo de la fuente es ERR_RELEASE_UNAVAILABLE y ningún otro código.
La regla del encoder no se comprueba en la librería: capsule.Encrypt y accesskey.Encode no reciben Registry, y la aplica la aplicación. Está documentado en extension.Placement.
El autor aprobó el texto el 28-09. El spec lleva esa fecha, y el SHA-256 de sus bytes LF, 5cfa3203…, está en spec/README.md y en el mensaje del tag.
main avanzó por fast-forward hasta 9ac9cd9 y lleva el tag spec-v0.8.2. Los dos están subidos.
App sincronizó testdata con 9ac9cd9 en 71ab8fb. Solo cambia testdata/README.md.

Siguen valiendo estas reglas:

App/testdata solo se actualiza desde datekeys-go, con scripts/sync-testdata.mjs, y nunca se generan fixtures en App. Una guarda falla si aparece un fichero de testdata que ningún test ejecuta.
Si cambia un texto de error de Go en los pasos 1 a 8, el TypeScript lo sigue. Hoy coinciden byte a byte.
Un cambio normativo posterior ya no modifica la v0.8.2: abre una versión nueva, con su caso en §76.

2.2 Fase 2: abrir cápsulas en el navegador

Plan: docs/PLAN_fase2_ibe_noble2.md v2, con las decisiones confirmadas por el autor. Los pasos 2 a 8 de su sección 10:

hecho el 28-09 (74e1215): age-encryption 0.3.1 y noble 2.4.0 como dependencias de ejecución, con sus guardas en src/lib/dependencies.test.ts y check-build.mjs. El README de App recoge el coste medido en el bundle, 73 KB con gzip para todo, y npm audit;
hecho el 28-09 (35be27c): ibe.ts sobre noble 2, con vectores de Go en src/lib/dkc/testing/ibe-vectors.json (scripts/ibe-go-vectors.go) y cobertura del 100 % fijada como umbral. Los argumentos del stanza y su paso al Stanza de age-encryption, que guarda el tipo en args[0], van al paso 7;
hecho el 28-09 (076f3db): release.ts, con verifyRelease en el orden y con los textos de provider.Verify, ReleaseSource y suppliedRelease. Solo verifica el scheme de Quicknet: otro da ERR_UNKNOWN_PROFILE. Reproduce los 7 casos del corpus que fallan en el paso 10;
hecho el 28-09 (97827ae), paso 5a: open.ts, los pasos 9 a 18 con el texto en claro en memoria. Las identidades estrictas de agewrap se apoyan en x25519.ts, que abre los stanzas de uno en uno. Usa @noble/ciphers 2.4.0, dependencia directa aprobada ese día: es la copia que ya usa age-encryption. Las identidades AGE-SECRET-KEY-1… se leen con bech32.ts. index.ts no reexporta aún la apertura, que metería noble en /inspect;
hecho el 28-09 (a89bee5), paso 5b. open acepta un Blob del que solo lee el prefijo de los pasos 1 a 8 (prefix.ts, movido de la página a la librería), calcula el capsule_digest en streaming (digest.ts) y descifra PAYLOAD_AGE en streaming. La salida puede ser un WritableStream, que se cierra tras el paso 18 y se aborta ante cualquier fallo. Comprobado en el navegador con OPFS real: un fallo de STREAM deja intacto el fichero;
siguiente, el paso 6, ya cubierto: la enmienda de canonicidad entró en la v0.8.2. Después viene el paso 7: el cifrado del stanza tlock (encryptOnG2RFC9380 y un Recipient propio) y la interoperabilidad de TypeScript a Go;
cifrado a nivel de stanza e interoperabilidad con Go;
la acción "abrir" en /inspect.

El vector de GT (vectors/tlock_ibe.json) ya está cubierto en App. El paso 9 de open.ts debe seguir la corrección 6: cualquier fallo de una fuente es ERR_RELEASE_UNAVAILABLE y ningún otro código.

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.

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.

3. Reglas del proyecto

Dependencias: en ejecución, solo age, drand, tlock y lo que ellas arrastran. El tooling de desarrollo sale de la lista del README. Nada nuevo sin aprobación escrita. Nunca GitHub como servicio.
Spec: en español, estilo RFC 2119. Todo cambio normativo se registra en §76 con su caso reproducible, y se actualiza el SHA-256 de spec/README.md.
Código y comentarios: en inglés. Commits con Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>.
Precedencia de errores (§69.1): trama; tipo y versión; perfil CBOR y CDDL; campos con código propio, en orden de clave. Entre objetos decide el orden de pasos de §63.
Subagentes: con model: "opus".

4. Documentos

Planes en App/docs: PLAN_libreria_go.md, PLAN_codec_cbor_y_pagina_svelte.md (v2) y PLAN_fase2_ibe_noble2.md (v2).
En datekeys-go:
- spec/DateKeys_Protocol_Specification_v0.8.2.md, spec/datekeys.cddl y spec/README.md;
- testdata/README.md, que documenta los ficheros compartidos para segundas implementaciones;
- docs/traceability.md y CHANGELOG.md.
Las herramientas de verificación de esta sesión (el diferencial Go/TypeScript de tsreview/ y las copias congeladas dkgo-ref-<commit>) están en el scratchpad temporal y pueden haber desaparecido. Su descripción está en los mensajes de los commits de App y en el README de App.

8.1 KiB Raw Blame History