El NIP-19 gana un límite

Por qué un límite de tamaño

Las entidades TLV del NIP-19 son abiertas por diseño. Un nprofile o un nevent puede llevar un número arbitrario de elementos TLV, incluidas varias sugerencias de relay, así que nada en la especificación anterior decía qué tan grande podía llegar a ser una de estas cadenas antes de que un decodificador debiera dejar de intentar procesarla. La especificación ya indicaba a los decodificadores que ignoraran los tipos TLV no reconocidos en lugar de generar un error. Combinado con la ausencia de un límite superior de longitud, un decodificador tenía que estar preparado para recorrer una cadena arbitrariamente larga solo para descubrir que debía ignorar la mayor parte de ella.

Establecer un tope recomendado da a quienes implementan la especificación un número concreto que comprobar antes de hacer cualquier trabajo de análisis. Un decodificador que ve una cadena de más de 5000 caracteres puede rechazarla de inmediato, en lugar de gastar tiempo y memoria recorriendo registros TLV que podrían extenderse indefinidamente. Ese es un patrón defensivo habitual para cualquier formato que acepte entradas de longitud variable influenciables por un atacante: acotar el tamaño de la entrada antes de hacer cualquier cosa costosa con ella.

Qué no cambia

El límite es un DEBERÍA, no un DEBE, y no toca la codificación en sí. npub, nsec, note, nprofile, nevent y naddr conservan la misma estructura bech32 y el mismo formato TLV para las entidades que lo usan. Nada cambia en cómo se producen o decodifican las entidades cortas ya existentes, como un npub simple, ya que estas quedan muy por debajo del nuevo tope en el uso normal. La línea solo afecta a los pocos casos en que una entidad, típicamente un nprofile o nevent cargado con varias sugerencias de relay, de otro modo no tendría un límite superior definido.

El panorama general

Las cadenas del NIP-19 están pensadas para pegarse en un chat, incrustarse en enlaces y codificarse en códigos QR, contextos donde una cadena sin límite es un problema práctico, no solo un inconveniente de análisis. Un código QR tiene límites físicos de tamaño, y un cliente que renderiza una cadena arbitrariamente larga está realizando un trabajo sin límite en respuesta a una entrada de usuario no autenticada. Una recomendación de 5000 caracteres da a cada implementación el mismo número sobre el cual diseñar, en lugar de dejar que cada cliente adivine dónde está el corte seguro.

Es un cambio de una sola línea en un NIP que ya lleva varias notas de este tipo. El NIP-19 también indica a los decodificadores que ignoren los tipos TLV que no reconocen, y restringe el uso de npub y nsec a la visualización y el copiado, manteniéndolos fuera de los eventos NIP-01 y de las respuestas NIP-05. Cada una de estas notas recorta un lugar donde una implementación podría, de otro modo, encontrarse con una entrada para la que no estaba preparada. Un límite de tamaño es la misma idea aplicada a la cadena completa en lugar de a una sola parte de su contenido.

Nada de esto cambia el aspecto de un npub, nprofile, nevent o naddr típico y válido. Una clave o referencia de evento habitual, incluso una con un par de sugerencias de relay, ronda a lo sumo unos pocos cientos de caracteres. La línea de los 5000 caracteres es un respaldo para los casos que quedan fuera de ese rango, no un cambio en cómo se construyen o leen normalmente estas entidades.