Cómo demostrar qué condiciones regían antes de un cambio

Resumen

Un borrador individual del 27 de octubre pide sellar cada versión de las condiciones y políticas de un servicio con nombre del documento, versión, URL y SHA-256 del texto plano. La versión sellada debe seguir disponible en esa dirección.
La propuesta vincula las claves de empresas y agentes a un dominio, conserva la historia de claves y somete un registro Merkle a puntos de control firmados y observadores. Eso fija quién declaró qué y cuándo; la verdad de lo declarado se examina por separado.

El enlace actual no estaba allí entonces

Una persona discute una operación pasada y recibe un enlace a las condiciones vigentes. El enlace no dice qué redacción acompañó la decisión original. Una frase sobre devoluciones, cargos o uso de datos puede ser precisamente el objeto del conflicto. Mostrar la cláusula de hoy deja sin presentar la pieza que permitiría discutir la de entonces. Una captura guardada por el usuario puede ayudar, pero deja la controversia en manos de dos custodios enfrentados: quien controla la web y quien tiene la imagen.

El borrador de Furkan Yanteri, fechado el 27 de octubre de 2026, formula una obligación precisa en su sección 4.2. Cada versión de los términos y políticas del servicio se incorpora mediante un sello que incluye el nombre del documento, un identificador de versión, una URL propia y el SHA-256 de su texto plano. Todo texto sellado debe permanecer accesible en esa URL. Cambiar la página principal sigue siendo posible. Hacer desaparecer sin rastro la antigua redacción se vuelve una operación detectable.

El hash permite comparar los bytes de un archivo recuperado con los bytes comprometidos en el sello. La URL permite encontrar el archivo. El registro público muestra que el compromiso estaba allí en un momento determinado. Si se borra el archivo, queda una huella sin texto para leer. Si queda el archivo pero nadie puede demostrar cuándo se fijó su hash, alguien podrá cuestionar su fecha. El diseño necesita las tres piezas juntas; un vistoso historial de cambios redactado por el propio servicio no las sustituye.

El Datatracker del IETF clasifica el texto como Internet-Draft individual y lo mantiene en estado I-D Exists. No es una norma aprobada por un grupo de trabajo ni el expediente de un conflicto real con una plataforma nombrada. El valor editorial está en la pregunta que obliga a hacer: cuando el operador modifica las reglas, ¿quién puede presentar el texto anterior sin pedirle permiso?

La clave que habla por el dominio

La propuesta prepara las declaraciones para que dos verificadores trabajen con la misma secuencia de bytes. Usa una forma restringida de JSON canónico basada en RFC 8785: claves ordenadas de modo recursivo, sin espacios prescindibles, con tipos de valor acotados. Una envoltura contiene el contenido, la clave pública y una firma Ed25519 conforme a RFC 8032. La firma identifica el mensaje firmado; no convierte una afirmación falsa en cierta.

La clave tampoco dice por sí sola a quién pertenece la voz. La sección 3.3 une las claves de empresas o agentes con un dominio mediante un registro DNS TXT bajo _humancollab. Un archivo HTTPS puede servir para la primera vinculación. El reemplazo de una clave ya vinculada exige prueba DNS; la clave antigua no puede reutilizarse en otro dominio. Una historia pública conserva cada clave y el índice del primer mensaje que firmó. Así, un cambio de control del dominio deja un antes y un después que el lector puede inspeccionar.

Conviene no regalar a esa prueba más poder del que tiene. Controlar el DNS permite presentar una clave en este esquema. No decide si el contenido de una declaración es correcto, si el empleado que la emitió podía obligar a su empresa o si un agente tenía permiso para concluir una transacción. La tabla de la sección 6 acota las conclusiones: firma válida y vínculo DNS señalan al controlador del dominio; inclusión en un punto de control observado acredita que la declaración apareció en el registro; otras fuentes pueden contradecirla. La atribución permite pedir cuentas a alguien concreto. No dicta la sentencia.

Un vigilante que vive en casa no basta

La sección 4.3 construye el registro como árbol Merkle, con reglas de hash alineadas con RFC 9162. El registro expide pruebas de inclusión y consistencia, firma sus cabeceras o puntos de control y ancla raíces publicadas en el tiempo mediante OpenTimestamps. Los observadores comparan cada punto nuevo con el anterior y guardan sus propias copias. La propuesta permite que cualquiera opere uno y pide al propio operador que mantenga otro fuera de la infraestructura del servicio.

La independencia no es decoración institucional. Dos puntos de control válidos, con el mismo tamaño de árbol y raíces distintas, prueban que el registro presentó historias incompatibles. Pero alguien debe conservar ambas. Si la única copia de los puntos de control reside bajo el mismo mando que controla la web, el registro puede acabar siendo otra sección elegante del sitio corporativo. La firma pone un nombre al archivo; el observador externo mantiene una memoria que el emisor no puede sustituir a voluntad.

En una disputa sobre condiciones, el expediente técnico útil reuniría el texto plano antiguo, su sello con versión y URL, una prueba de inclusión contra un punto de control conservado fuera del servicio y la historia de la clave vinculada al dominio en aquella fecha. Esos objetos permiten comprobar palabras, tiempo y autoría. Para decidir si la condición era exigible, si el usuario la vio o si un agente actuó con mandato, harán falta los hechos propios de la operación. Al menos la discusión partirá de las palabras que existían entonces.

Una empresa necesita poder cambiar reglas. Lo que no necesita para hacerlo es quedarse con la única llave del pasado. La propuesta convierte la frase «muéstreme las condiciones de aquel día» en una solicitud verificable, no en una carrera para encontrar una captura olvidada.