El formato como decisión de décadas

Un formato parece una decisión de implementación y es una decisión de horizonte temporal. Cuando eliges cómo se codifican unos datos estás fijando, sin decirlo, cuánto tiempo seguirán siendo interpretables y qué hará falta para interpretarlos. La pregunta correcta no es si el formato es cómodo hoy, sino qué debe seguir existiendo dentro de treinta años para que ese flujo de bytes recupere su significado. Un fichero en un disco exige, para seguir siendo legible, que exista una especificación y un lector; una llamada a una API exige que exista una empresa, un dominio, un certificado, una relación de facturación y un equipo que siga desplegando. La diferencia entre ambas listas no es de grado. Esta lección examina qué hace que un formato dure, por qué abierto y legible no son sinónimos, y por qué el propio local-first alberga aquí una contradicción interna que conviene mirar de frente.

Las cuatro capas de la legibilidad futura

Conviene empezar deshaciendo una simplificación que domina la conversación: se habla de formatos duraderos como si la durabilidad fuera un atributo del formato, cuando en realidad es el resultado de una cadena que atraviesa cuatro niveles distintos y que puede romperse en cualquiera de ellos por causas sin relación entre sí.

Que un dato siga siendo legible dentro de décadas no es una propiedad, son cuatro propiedades encadenadas, y la cadena se rompe por su eslabón más débil. La primera capa es el medio: los bytes deben seguir existiendo, lo que exige copias, verificación periódica y migración de soporte, porque ningún soporte físico dura tanto como la vida útil del contenido. La segunda es el contenedor: la codificación de caracteres, la compresión, el empaquetado. La tercera es la estructura: el esquema que dice qué campos hay y cómo se anidan. La cuarta es la semántica: qué significan esos campos, que es la única capa que no vive en los bytes y que, cuando falta, deja un artefacto perfectamente decodificable y perfectamente ininteligible.

Conviene fijar qué pregunta plantea cada capa, porque las respuestas se buscan en sitios distintos y con presupuestos distintos:

1. Medio. Siguen existiendo los bytes. Se responde con copias múltiples, sumas de verificación y migración periódica de soporte.
2. Contenedor. Se puede desempaquetar el flujo. Se responde eligiendo codificaciones y compresiones con implementaciones libres y antiguas.
3. Estructura. Se puede recuperar la organización interna. Se responde con un esquema documentado y versionado junto al artefacto.
4. Semántica. Se sabe qué significa cada campo. Se responde con documentación embebida, nombres explícitos y vocabularios estables.

El criterio unificador es la autodescripción: cuánto significado puede recuperar un lector futuro a partir del artefacto y nada más, sin acceso al autor, a su documentación interna ni a su base de datos. Un CSV con encabezados es débilmente autodescriptivo; un JSON de identificadores opacos que apuntan unos a otros es textual, legible por una máquina y semánticamente mudo. Formato de texto y formato comprensible son cosas distintas, y confundirlas es el error más frecuente en esta discusión.

flowchart TD
M[Medio: los bytes siguen existiendo]
M --> C[Contenedor: codificacion y empaquetado]
C --> E[Estructura: esquema y anidamiento]
E --> S[Semantica: que significa cada campo]
S --> L[Interpretable sin el autor dentro de tres decadas]
S -.si falta.-> X[Artefacto decodificable e ininteligible]
style L fill:#a6e3a1,color:#11111b
style X fill:#f38ba8,color:#11111b

Jeff Rothenberg lo formuló en 1995 con una frase que envejeció demasiado bien: los documentos digitales duran para siempre, o cinco años, lo que ocurra primero. Tres décadas después el diagnóstico se sostiene, y lo interesante es que el fallo casi nunca ocurre en la primera capa. Los bytes suelen sobrevivir. Lo que se evapora es la cuarta.

Abierto, implementable, implementado

Se dice de un formato que es abierto con una ligereza que oculta al menos cuatro condiciones distintas, y solo cumplirlas todas produce longevidad real:

1. Especificación publicada y completa. Sin remisiones a comportamientos no documentados ni apéndices que digan lo que la implementación de referencia haga.
2. Implementable sin permiso. Libre de patentes activas y de términos de licencia que restrinjan escribir un lector independiente.
3. Al menos una implementación independiente. Una especificación que nadie ha implementado dos veces es una hipótesis, no un estándar, porque nadie ha comprobado que se pueda.
4. Corpus de pruebas de conformidad. Ficheros de ejemplo con el resultado esperado, para verificar que dos lectores coinciden en los casos difíciles.

La cuarta condición es la que más se omite y la que más decide, porque sin corpus las divergencias entre implementaciones no se detectan hasta que ya hay millones de ficheros escritos con dos interpretaciones distintas del mismo campo.

Hay una quinta condición implícita que rara vez se enuncia y que decide tanto como las otras cuatro: la estabilidad de la especificación en el tiempo. Un formato cuya norma se revisa cada dos años con cambios incompatibles obliga a que cada lector declare qué versión entiende, y a los treinta años el conjunto de artefactos escritos bajo versiones distintas se comporta como una familia de formatos parecidos y no como uno solo. La longevidad premia a los formatos aburridos que casi no cambian, y castiga a los que evolucionan bien.

El caso aleccionador es OOXML: norma ISO, especificación publicada de miles de páginas y, en la práctica, una sola implementación que la lee con fidelidad completa. La apertura formal se cumplió y la longevidad no llegó, porque la complejidad de la especificación actuó como barrera de entrada tan eficaz como habría actuado el secreto. El contraste con los formatos que sí duraron es instructivo, porque las razones se repiten:

• Texto plano. Sobrevivió porque su intérprete es trivial y porque su semántica la pone el lector humano, no una tabla interna.
• TIFF y PNG. Sobrevivieron por especificación estable, implementaciones libres desde el principio y ausencia de trabas de patente en el caso de PNG, que nació justamente como respuesta a una de ellas.
• PDF/A. Sobrevivió porque su perfil de archivo prohíbe explícitamente lo que impedía conservar: dependencias externas, contenido activo y tipografías no embebidas.
• SQLite. Recomendado por la Biblioteca del Congreso de Estados Unidos como formato de conservación por su especificación estable, su formato de fichero documentado y su promesa pública de compatibilidad hasta bien entrado el próximo siglo.

Frente a ellos, el cementerio, con causas de muerte igual de repetidas: WordPerfect y Lotus 1-2-3 murieron con la cuota de mercado de su producto; Flash murió porque su intérprete era un binario propietario que alguien podía dejar de mantener y lo dejó; los formatos nativos de programas de diseño discontinuados murieron porque nunca hubo especificación y su semántica se fue con el equipo que la conocía.

El fichero frente a la interfaz remota

Aquí está el argumento central de la lección, y conviene enunciarlo sin exageración porque exagerado es falso. Un fichero y una API no se distinguen por su fiabilidad instantánea —en el día a día una API bien operada es más fiable que el disco de un portátil—, sino por quién soporta el coste de su continuidad y por si puede dejar de pagarlo.

La existencia de un fichero es el estado por defecto: para que siga ahí no hace falta que nadie decida nada. Su degradación es pasiva —corrupción de bits, obsolescencia del soporte— y se combate con procedimientos bien conocidos: varias copias, sumas de verificación, verificación periódica, migración planificada de medio. La existencia de una interfaz remota es lo contrario: es un gasto recurrente que alguien elige seguir pagando cada mes. Su degradación es activa, porque no ocurre por abandono sino por decisión: se deprecan versiones, cambia el esquema de autenticación, se introducen cuotas, se retiran campos, se cierra el producto. Y hay una asimetría decisiva en el fallo: si el mantenedor de un formato desaparece, el fichero sigue ahí y alguien puede escribir un lector; si el operador de una API desaparece, no queda nada que leer.

De ahí la formulación honesta, que no es un eslogan: un fichero en disco no es mágicamente eterno y sin copias es frágil, pero su continuidad depende solo de ti, mientras que la de una API depende de una voluntad ajena que tú no controlas y que tiene fecha de caducidad económica. Local-first no promete inmortalidad; promete que la carga de la continuidad recae sobre quien tiene interés en que continúe.

flowchart TD
F[Fichero en disco]
A[Interfaz remota]
F --> F1[Continuidad por defecto sin decision de nadie]
F --> F2[Degradacion pasiva por medio y por bits]
F --> F3[Si el mantenedor desaparece el artefacto sigue ahi]
A --> A1[Continuidad como gasto recurrente que alguien elige pagar]
A --> A2[Degradacion activa por deprecacion y cambio de version]
A --> A3[Si el operador desaparece no queda nada que leer]
style F1 fill:#a6e3a1,color:#11111b
style F3 fill:#a6e3a1,color:#11111b
style A1 fill:#f9e2af,color:#11111b
style A3 fill:#f38ba8,color:#11111b

Hay que resistir, eso sí, la lectura triunfalista del diagrama. La degradación pasiva no es benigna: los bits se corrompen, los sistemas de ficheros fallan en silencio y un disco olvidado en un cajón durante quince años es un billete de lotería. La conservación seria de ficheros es una disciplina con procedimientos propios —varias copias en soportes y ubicaciones distintas, verificación periódica de sumas, migración planificada antes de que el soporte quede obsoleto— y quien elige la soberanía sin adoptarlos no ha ganado longevidad, solo ha cambiado un riesgo administrado por otro que nadie administra.

La contradicción interna del local-first

Hay además una diferencia de quién puede reparar el daño. Si un formato de fichero resulta tener un error de diseño, cualquiera con la especificación puede escribir un conversor y arreglar su propio archivo, incluso décadas después. Si una interfaz remota introduce un cambio incompatible o retira un campo, no hay nada que un tercero pueda hacer salvo adaptarse o marcharse, y si el servicio ya cerró, ni siquiera eso. La reparabilidad no es una propiedad del artefacto: es una propiedad de la relación, y depende de si el conocimiento necesario para actuar está distribuido o concentrado.

Toca ahora la parte incómoda, y sería deshonesto omitirla en un nivel dedicado a la propiedad. El formato que hace posible la convergencia sin árbitro —el estado interno de un CRDT— es, medido con los criterios de este capítulo, un mal formato de conservación. Es binario, está optimizado para tamaño y para velocidad de fusión, guarda metadatos de identidad y causalidad que solo tienen sentido dentro del algoritmo, y su semántica no reside en una especificación estable sino en la implementación de una biblioteca que cambia de versión. Un documento de Automerge o de Yjs abierto dentro de veinte años sin la biblioteca correcta es exactamente el artefacto decodificable e ininteligible del diagrama. El movimiento que hizo de la longevidad uno de sus siete ideales trabaja, en su capa técnica, con formatos que hoy no la garantizan.

La tensión es genuina y no se resuelve con voluntarismo, porque las dos propiedades tiran en direcciones opuestas por razones técnicas y no por descuido. Un formato de conservación quiere ser simple, redundante y explícito, porque esas son las cualidades que permiten reconstruir un lector. Un formato de fusión quiere ser compacto, denso y lleno de metadatos internos, porque de ahí sale el rendimiento que hace posible editar un documento grande en un dispositivo modesto. Pedir un solo artefacto que sea las dos cosas es pedir un compromiso que degrada ambas.

El desmentido parcial existe y merece reconocerse: los proyectos maduros han empezado a publicar especificaciones de su formato de almacenamiento y a comprometerse con la compatibilidad hacia atrás, que es justamente el camino que convirtió a SQLite en formato de archivo. Pero es un trabajo en curso, no una propiedad conseguida, y presentarlo de otro modo sería vender el ideal como si fuera el estado del arte.

Conviene además distinguir tres grados de opacidad dentro de esa familia, porque tratarlos como uno solo es injusto con las diferencias reales:

• Opacidad total. El formato es un volcado de estructuras internas sin documentar, atado a la versión exacta de la biblioteca que lo escribió. Solo ese código lo lee.
• Opacidad documentada. Existe una especificación del formato de almacenamiento y un compromiso de compatibilidad hacia atrás. Un tercero podría escribir un lector con esfuerzo.
• Opacidad con proyección. Además de lo anterior, el sistema escribe de forma continua una representación legible del contenido. La opacidad deja de importar para la conservación.

La respuesta arquitectónica razonable no es renunciar al CRDT sino separar dos roles que solemos confundir. El formato de trabajo puede ser opaco, rápido y versionado, porque su función es soportar la edición concurrente. El formato durable debe ser una proyección legible, estable y autodescriptiva del mismo contenido, generada de forma continua y no bajo demanda.

Un directorio de ficheros de texto escrito junto al artefacto binario en cada guardado cuesta poco espacio, cuesta menos tiempo de lo que cuesta el propio guardado y cambia por completo el perfil de riesgo a treinta años. Lo que se pierde en esa proyección es la historia, la información de fusión y la posibilidad de reanudar la colaboración desde ella; lo que se conserva es exactamente lo que importa cuando ya no hay colaboración posible porque no queda nadie con quien colaborar. Aceptar esa asimetría —proyección con pérdida pero legible, artefacto completo pero opaco— es la decisión de diseño correcta, y la lección siguiente sobre exportación explica por qué esa proyección debe ser un proceso continuo y no un botón.