NIP-02 da rutas resolubles a los apodos

Cada componente sigue la lista de una persona

El texto fusionado de NIP-02 define la resolución componente por componente. Si la lista del usuario asigna erin a una clave pública y la lista de Erin asigna charlie a otra, un cliente puede resolver ~/erin/charlie: primero busca erin en el contexto local, obtiene el evento kind 3 más reciente de Erin y busca allí charlie.

La versión anterior mostraba nombres derivados como frank.david.erin, pero no fijaba una gramática de ruta ni un procedimiento de búsqueda. La nueva versión ordena la relación como la recorre un resolutor: comienza en una raíz, encuentra el primer nombre y usa la lista de ese perfil para el siguiente.

La forma ~ usa al usuario conectado como raíz relativa. NIP-02 también ofrece dos ejemplos de raíz absoluta cuando no hay sesión o su contexto no es relevante:

~npub1.../erin/charlie
[email protected]/erin/charlie

Los ejemplos indican qué contexto de nombres inicia la ruta. No crean un registro global. Cada componente posterior depende del apodo elegido en la lista del perfil anterior.

Una cadena legible no es una prueba de confianza

Las rutas pueden mostrar contexto social sin pedir a una única autoridad que asigne todos los nombres. En una interfaz de web of trust, ~/erin/charlie puede resultar más informativo que una clave desnuda porque expresa cómo llega el usuario a Charlie a través de Erin.

No debe tratarse como prueba criptográfica de identidad. Un evento kind 3 está firmado y permite verificar quién publicó cada correspondencia, pero su autor puede elegir un apodo engañoso, cambiarlo o apuntarlo a otra clave. NIP-02 también establece que una nueva lista sustituye a la anterior. El resolutor necesita el evento válido más reciente de cada paso.

La disponibilidad impone otro límite. Una ruta larga puede exigir varias listas almacenadas en relays. Un evento ausente o antiguo puede detener la resolución aunque las claves sigan siendo válidas. Conviene que los clientes muestren la clave resuelta, la raíz y cualquier paso fallido, en vez de presentar la ruta como un nombre incuestionable.

Quedan detalles de análisis abiertos

La fusión modifica un solo archivo, con diez líneas añadidas y veinte eliminadas. Define ejemplos relativos y absolutos, pero no especifica cómo escapar apodos que contengan /, espacios u otros caracteres especiales. Esos casos se plantearon en comentarios posteriores a la fusión y el NIP actual todavía no los resuelve.

La pull request tampoco aporta evidencia de una implementación publicada. Es una aclaración de la especificación, no una prueba de que un cliente concreto ya pueda introducir, mostrar o resolver la notación. La interoperabilidad dependerá de que los clientes acuerden el análisis y la forma de informar rutas incompletas.

El límite útil queda claro: NIP-02 describe una cadena de nombres asignados localmente. No los convierte en identificadores únicos globales, no sustituye la verificación de claves públicas y no establece una puntuación de confianza.