Nostr es un protocolo abierto de eventos firmados que los clientes intercambian mediante relays independientes. Las redes sociales son un uso; el protocolo no tiene blockchain propia ni consenso común entre todos los relays.
Un evento contiene pubkey, created_at, kind, tags, content, id y sig. NIP-01 obtiene id con SHA-256 de una serialización precisa y utiliza firmas BIP340 sobre secp256k1. El cliente verifica integridad y autorización por la clave. El autor declara created_at; no es una marca temporal independiente ni prueba de veracidad. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]
El cliente publica EVENT y se suscribe con REQ mediante WebSocket. OK comunica aceptación o rechazo por ese relay. EOSE termina la lista de eventos almacenados, no necesariamente la suscripción a nuevos eventos. Ninguno confirma recepción por el destinatario, replicación en toda la red o almacenamiento permanente. [Nostr — NIP-01: Basic protocol]
Dentro de un filtro deben cumplirse todas las condiciones: autor y tipo significan AND. Varios filtros en un REQ se combinan mediante OR; basta uno. limit restringe la lista inicial, no la cantidad de eventos futuros. Un resultado ausente puede reflejar un historial limitado del relay, no la inexistencia del evento. [Nostr — NIP-01: Basic protocol]
Los eventos reemplazables se comparan por pubkey y kind; los direccionables también por la etiqueta d. Una versión nueva puede sustituir a otra; si empatan las fechas, prevalece el id lexicográficamente menor. No se espera almacenar eventos efímeros. Son reglas del relay, no un archivo global inmutable; las implementaciones pueden diferir. [Nostr — NIP-01: Basic protocol]
NIP-19 utiliza Bech32 para la representación al usuario: npub es la clave pública y nsec la privada. Codificar no es cifrar. Compartir nsec entrega la clave secreta, no solo un enlace al perfil. Los eventos y filtros NIP-01 usan claves públicas hexadecimales, no su representación npub. [Nostr — NIP-19: Encoded entities]
NIP-05 vincula un nombre parecido a un correo con una clave pública según la respuesta del dominio. Acredita esa relación, no la identidad real ni la honradez. El cliente debe seguir la clave original: si el dominio asocia el nombre a otra, no debe sustituir automáticamente con ella el perfil seguido. [Nostr — NIP-05: Internet identifiers]
NIP-09 define la petición del autor de eliminar sus eventos. Antes de ocultarlos, el cliente debe comprobar que evento original y solicitud comparten clave pública. Los relays y clientes pueden tramitarla, pero el protocolo no puede eliminar todas las copias descargadas o conservadas. Borrar en una interfaz no demuestra un borrado global. [Nostr — NIP-09: Deletion requests]
NIP-44 define un payload cifrado, no un sistema completo de mensajes privados; NIP-17 añade envolturas y reglas de entrega. NIP-44 por sí solo no ofrece forward secrecy si después se compromete la clave. Las direcciones de red, tiempos y comportamiento del cliente siguen importando con contenido cifrado. El soporte de cada NIP depende de la aplicación. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]
Para obtener la imagen más completa, lee esta entrada junto con Nostr Wallet Connect, Firma Schnorr, Clave privada, Privacidad en Bitcoin, Seudonimidad. También enlazan con esta entrada Nostr Wallet Connect.