9.2 KiB
Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 29)
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) y el 29 tras cerrar la fase 2 (§2.2). 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 |
48d6704 |
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 con la acción "abrir". testdata sincronizado a 9ac9cd9. Fase 2 completa (pasos 2 a 8), incluidos el cifrado tlock y la interoperabilidad de TypeScript a Go. Los 65 casos del corpus pasan por open con el código y el paso de Go. 2 611 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 60ssobre9ac9cd9, 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/grpc1.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.
- GO-2026-6443, en
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 sobrec57ed48que absorbe el WIP69a3342. 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_UNAVAILABLEy ningún otro código.
- La regla del encoder no se comprueba en la librería:
capsule.Encryptyaccesskey.Encodeno recibenRegistry, y la aplica la aplicación. Está documentado enextension.Placement. - El autor aprobó el texto el 28-09. El spec lleva esa fecha, y el SHA-256 de sus bytes LF,
5cfa3203…, está enspec/README.mdy en el mensaje del tag. mainavanzó por fast-forward hasta9ac9cd9y lleva el tagspec-v0.8.2. Los dos están subidos.Appsincronizótestdatacon9ac9cd9en71ab8fb. Solo cambiatestdata/README.md.
Siguen valiendo estas reglas:
App/testdatasolo se actualiza desdedatekeys-go, conscripts/sync-testdata.mjs, y nunca se generan fixtures enApp. Una guarda falla si aparece un fichero detestdataque 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-encryption0.3.1 y noble 2.4.0 como dependencias de ejecución, con sus guardas ensrc/lib/dependencies.test.tsycheck-build.mjs. El README deApprecoge el coste medido en el bundle, 73 KB con gzip para todo, ynpm audit; - hecho el 28-09 (
35be27c):ibe.tssobre noble 2, con vectores de Go ensrc/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 alStanzadeage-encryption, que guarda el tipo enargs[0], van al paso 7; - hecho el 28-09 (
076f3db):release.ts, converifyReleaseen el orden y con los textos deprovider.Verify,ReleaseSourceysuppliedRelease. Solo verifica el scheme de Quicknet: otro daERR_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 deagewrapse apoyan enx25519.ts, que abre los stanzas de uno en uno. Usa@noble/ciphers2.4.0, dependencia directa aprobada ese día: es la copia que ya usaage-encryption. Las identidadesAGE-SECRET-KEY-1…se leen conbech32.ts.index.tsno reexporta aún la apertura, que metería noble en/inspect; - hecho el 28-09 (
a89bee5), paso 5b.openacepta unBlobdel que solo lee el prefijo de los pasos 1 a 8 (prefix.ts, movido de la página a la librería), calcula elcapsule_digesten streaming (digest.ts) y descifraPAYLOAD_AGEen streaming. La salida puede ser unWritableStream, 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; - el paso 6 está cubierto: la enmienda de canonicidad entró en la v0.8.2;
- hecho el 28-09 (
66970cf), paso 7:encryptOnG2RFC9380ytimeRecipient. Con sigma fijo, el cifrado reproduce byte a byte los vectores de Go. Go abrió los cuerpos IBE y los ficherosageque cifró esta librería, contlock.TimeUnlocky conagewrap.NewTimeIdentity. Todo está ensrc/lib/dkc/testing/tlock-vectors.json; - hecho el 28 y 29-09 (
48d6704), paso 8: la acción "abrir" en/inspect, cargada bajo demanda, con la política aprobada por el autor el 28-09 tras revisar lo que dice el protocolo:- el release lo pega quien abre, o sale del registro del fixture, y la página nunca lo pide a la red;
- el texto en claro de un fichero propio va a un fichero temporal de OPFS (§56), que se borra;
- los avisos de licencia se publican en
licenses.txt. Una revisión adversarial confirmó 15 hallazgos, todos corregidos. Los detalles y las comprobaciones en el navegador están en la fila 8 del plan.
La lectura del protocolo del 28-09 deja dos SHOULD para más adelante: §48 (varios relays) y §49 (obtener el release directamente del proveedor). Los cubrirá una fuente drand opcional del SDK, nunca activa por defecto en la página (sección 12 del plan).
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.comy, si se quiere, unsecurity.txten la web. Después, actualizarSECURITY.md, que hoy diceinfo@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áginago-importendatekeys.com. Después: renombrar el módulo y poner el tagv0.1.0cuandogo getfuncione desde una máquina limpia. - Decidir si
Apppasa de0.1.0-deva0.1.0, ahora que la fase 2 está completa.
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,tlocky 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) yPLAN_fase2_ibe_noble2.md(v2). - En
datekeys-go:spec/DateKeys_Protocol_Specification_v0.8.2.md,spec/datekeys.cddlyspec/README.md;testdata/README.md, que documenta los ficheros compartidos para segundas implementaciones;docs/traceability.mdyCHANGELOG.md.
- Las herramientas de verificación de esta sesión (el diferencial Go/TypeScript de
tsreview/y las copias congeladasdkgo-ref-<commit>) están en el scratchpad temporal y pueden haber desaparecido. Su descripción está en los mensajes de los commits deAppy en el README deApp.