Nostr

Anna encuentra en Nostr autores a los que quiere seguir. Más adelante, su aplicación deja de gustarle. Si utiliza de forma segura la misma clave privada o un dispositivo de firma conectado en otra aplicación, puede conservar su identidad. La clave pública permite reconocerla y verificar sus firmas; la privada permite firmar como ella. Por eso npub y nsec son tan distintos. Según NIP-19, representan las claves pública y privada mediante la codificación Bech32. Los NIP son documentos numerados que describen las reglas y extensiones de Nostr. Codificar no es cifrar: un nsec no es un enlace inofensivo al perfil que se pueda compartir con cualquiera. Conservar la identidad tampoco garantiza que la nueva aplicación encuentre todas las publicaciones antiguas o importe todos los ajustes. [2] [7]

La aplicación, llamada cliente, firma la publicación y la envía a los relays elegidos. Un relay es un servidor que acepta mensajes y los guarda o retransmite según sus propias reglas. La aplicación de Petr se conecta a relays y pide las publicaciones que le interesan. No hay un único servidor central ni obligación de copiarlo todo en cada servidor. Técnicamente, cliente y relay se comunican mediante WebSocket, una conexión que permanece abierta: EVENT transporta el mensaje, REQ abre una suscripción y OK comunica aceptación o rechazo. Ni siquiera un OK positivo confirma la entrega a Petr o el almacenamiento permanente. EOSE señala el final de los resultados guardados para esa consulta; la suscripción puede seguir recibiendo mensajes nuevos. [1] [7]

Cuando Petr recibe un mensaje, su aplicación comprueba que la firma corresponde a la clave pública indicada y que los datos firmados no han cambiado. Eso no demuestra que el mensaje sea cierto ni revela la identidad civil de su autor. El autor también indica la hora de creación, por lo que no es un sello de tiempo independiente. Para quien quiera profundizar: el registro llamado event contiene pubkey, created_at, kind, tags y content, es decir, clave, hora, tipo, etiquetas y contenido. SHA-256 convierte su representación exactamente definida en un valor de comprobación corto llamado id. Sirve para detectar cambios en los datos firmados. El campo sig contiene una Schnorr Signature conforme a BIP340 sobre la curva secp256k1. Dice «el titular de la clave correspondiente firmó estos datos», no «puedes confiar en esta afirmación». [1]

Una clave pública larga resulta difícil de recordar. NIP-05 permite asociarla a un identificador parecido a una dirección de correo electrónico. La aplicación pregunta al dominio correspondiente qué clave está vinculada al nombre y compara la respuesta con la clave del perfil. Así verifica esa relación con el dominio, no automáticamente el nombre real, la reputación o la fiabilidad de una persona. El operador del dominio puede cambiar la asociación. Si Anna ya sigue a alguien, la referencia debe seguir siendo la clave pública original; reasignar el mismo nombre no debe cambiar silenciosamente a quién sigue. La seudonimidad permite utilizar un identificador estable en lugar del nombre civil, pero no garantiza anonimato. [3]

Petr no necesita descargar todos los mensajes. Envía un filtro, por ejemplo para ciertos autores y un tipo concreto de publicación. Las distintas condiciones de un filtro se unen mediante AND: deben cumplirse todas. Varios valores permitidos para una condición son alternativas OR, igual que varios filtros dentro de un mismo REQ. Basta con cumplir uno de esos filtros. limit restringe el lote inicial de resultados almacenados, no automáticamente los futuros mensajes de la suscripción. NIP-01 utiliza claves hexadecimales en eventos y filtros, no el formato npub destinado al usuario. Una búsqueda sin resultados puede deberse al filtro, al servidor elegido o a su historial; no demuestra que la publicación no exista en ningún sitio. [1]

Anna cambia la descripción del perfil y quiere que los demás vean la nueva. Por eso Nostr distingue qué deben conservar los relays. Para eventos reemplazables, seleccionan el registro más reciente de la misma pareja pubkey y kind. Los eventos direccionables añaden el valor de la etiqueta d, que distingue, por ejemplo, documentos diferentes del mismo autor. Si varios registros reemplazables tienen la misma hora, se recomienda conservar el id menor en orden lexicográfico: el que aparece primero al ordenar su representación. Los eventos temporales, llamados ephemeral, ni siquiera están destinados a almacenarse. Son convenciones y el comportamiento de los relays puede variar. Nostr no es, por tanto, un registro en el que toda la red acuerde una única historia inmutable. [1]

Anna descubre que publicó algo que quería mantener privado. NIP-09 permite enviar una solicitud de borrado firmada. Antes de aplicarla, el cliente debe comprobar que la solicitud y la publicación original pertenecen a la misma clave pública; otra persona no puede borrar el mensaje de Anna simplemente señalándolo. Los servidores y aplicaciones que cooperen pueden retirar el contenido o dejar de mostrarlo. La petición no elimina todas las copias, capturas de pantalla o archivos independientes. Ocultar una publicación en una aplicación tampoco demuestra que otro servidor haya dejado de ofrecerla. Importa más lo que publicas que la existencia de un botón Borrar. [4]

Cualquiera que obtenga una publicación pública puede leerla; firmarla no oculta su contenido. Los mensajes privados usan reglas adicionales. NIP-44 describe el cifrado del contenido, mientras que NIP-17 aborda su envoltura y entrega con otras capas de protección. Eso no equivale a anonimato automático: las direcciones de red, los horarios y el comportamiento de la aplicación aún pueden revelar información. Este cifrado tampoco ofrece forward secrecy, la protección de conversaciones pasadas si posteriormente se filtra una clave de larga duración. Quien obtenga la clave privada necesaria y mensajes cifrados capturados antes podrá leer también comunicaciones anteriores. Comprueba qué extensiones admite realmente la aplicación; la etiqueta «Nostr» no describe por sí sola su privacidad. [5] [6]