Con qué se termina
Una sesión iniciada en una aplicación web de Nostr, donde la aplicación puede publicar en nombre de uno pero nunca vio la clave privada, y una comprobación que confirma que eso es cierto de verdad.
No hay cuenta que crear, ni contraseña, ni correo. La identidad es un par de claves: npub…
es la mitad pública que ve el resto, nsec… es la mitad privada que firma. Iniciar sesión
es demostrar el control de la mitad privada, y toda la pregunta de diseño es si esa prueba
se da entregando la clave o conservándola y devolviendo una firma.
Antes de empezar
- Un par de claves. Si no hay uno, el firmante que se instala en el paso 1 lo crea. Quien ya tiene bitcoin y quiere que ambos compartan un respaldo puede derivar una identidad de Nostr desde su seed en lugar de generar una clave suelta.
- Un navegador propio. No una máquina compartida, ni una portátil de trabajo con extensiones administradas.
- Un lugar donde anotar la clave privada, fuera de línea, antes de usarla en ningún lado. La misma disciplina que una frase de recuperación de Bitcoin, por la misma razón.
Comprobado en agosto de 2026 contra NIP-07 y NIP-46 tal como están especificados, nos2x para Chromium, nos2x-fox para Firefox, la extensión de Alby, nsec.app y Amber 6.5.2, publicada el 18 de agosto de 2026.
El costo que se está aceptando
Una clave de Nostr no se puede rotar. De esa frase cuelga el resto de la guía, y casi nada de lo que se escribe sobre Nostr lo dice en voz alta.
En cualquier servicio normal, una contraseña filtrada es una molestia: se cambia, y la
anterior deja de servir. En Nostr no hay servidor que guarde un registro de quién es cada
uno, así que no hay nada que actualizar. La clave pública es la identidad. Si el nsec se
filtra, quien lo tenga puede publicar en nombre de uno para siempre, y el único remedio es
abandonar la identidad, empezar con una clave nueva y pedirle a cada persona que seguía a la
anterior que siga a la nueva. Los seguidores, el historial y la reputación no viajan.
Por eso toda recomendación de abajo trata de mantener la clave fuera del navegador, y por eso el tercer método aparece solamente para poder reconocerlo y rechazarlo.
Pasos
El camino recomendado es una extensión de navegador, porque es el que no le pide nada a la aplicación web más allá de un estándar que todo cliente serio ya implementa.
- Instalar un firmante NIP-07 para el navegador: nos2x en Chromium, nos2x-fox en Firefox, o la extensión de Alby en cualquiera de los dos. Instalarlo desde la tienda de extensiones del propio navegador o desde la página de releases del proyecto, y revisar quién lo publica.
- Abrir la extensión y pegar una clave privada existente, o dejar que genere una.
- Anotar la clave privada en papel, fuera de línea, ahora. Es la única copia, y perderla pierde la identidad tan completamente como filtrarla.
- Abrir la configuración de la extensión y confirmar que la clave pública que muestra es la identidad que se quería usar.
- Ir a la aplicación web de Nostr y elegir la opción de inicio de sesión que menciona una
extensión,
window.nostro NIP-07. - Aprobar el permiso que pide la extensión. Conviene otorgar firma para los tipos de evento que la aplicación realmente usa, en lugar de una aprobación general, si la extensión ofrece esa opción.
- Confirmar que la aplicación muestra el
npubpropio. Con eso la sesión está iniciada.
En un teléfono, o para no instalar nada
Las extensiones son incómodas en móvil. Kiwi Browser, que era la respuesta habitual, se discontinuó en enero de 2025; Firefox para Android sigue admitiendo nos2x-fox, y esa sigue siendo la ruta móvil más simple.
La alternativa es la firma remota, especificada en NIP-46 como
Nostr Remote Signing. La clave
queda en una aplicación firmante, la aplicación web le manda una solicitud cifrada por un
relé, y el firmante devuelve una firma. Existen dos formatos de conexión: bunker://, que
genera el firmante y se pega en la aplicación, y nostrconnect://, que genera la aplicación
y escanea el firmante.
- Instalar un firmante que hable NIP-46: Amber en Android, o nsec.app en un navegador.
- Cargar la clave ahí, o generar una en ese mismo lugar.
- En la aplicación web, elegir la opción de firma remota o de "conectar".
- Escanear el código
nostrconnect://con el firmante, o pegar en la aplicación la cadenabunker://del firmante. - Aprobar la conexión en el firmante, y definir qué permisos puede usar sin volver a preguntar.
El método que hay que rechazar
Algunas aplicaciones ofrecen una casilla para pegar el nsec directamente. No conviene
usarla con una identidad que importe. La aplicación pasa a tener la clave, y dado el párrafo
de arriba sobre la rotación, "pasa a tener la clave" y "es dueña de la identidad" son la
misma afirmación. Si no queda otra que probar una aplicación que no ofrece nada más, se
genera una clave descartable para ella y no se reutiliza esa clave en ningún otro lado.
Cómo comprobar que salió bien
- Comparar la clave pública que muestra la aplicación con la del firmante. Comparar los
primeros y los últimos seis caracteres del
npuben los dos lugares. Una aplicación que muestra una identidad distinta de la esperada es la falla que esta comprobación detecta. - Publicar una nota y leerla desde otro lado. Abrir un segundo cliente, o un explorador
público de relés, y encontrar la nota bajo el
npubpropio. Eso prueba que la firma era válida y que el evento llegó a los relés, en lugar de quedar en el estado local de la aplicación. - Confirmar que la aplicación no puede firmar en silencio. Disparar otra acción firmada y comprobar que el firmante pregunta, o que está firmando bajo un permiso otorgado a propósito. Si una página web puede firmar cualquier cosa en cualquier momento sin que uno se entere, la extensión está configurada con demasiada holgura.
- Cerrar la sesión y volver a iniciarla. Un inicio de sesión que funciona una sola vez, o que guarda la clave en la página sin decirlo, falla esta comprobación.
Si algo sale mal
La aplicación no ofrece inicio de sesión con extensión. La extensión no está inyectando
window.nostr. Recargar la página después de instalarla, comprobar que está habilitada para
ese sitio, y comprobar que no está bloqueada en una ventana privada.
No pasa nada al aprobar el permiso. Algunas aplicaciones piden un método opcional de
NIP-07 que el firmante no implementa. La especificación solo exige getPublicKey y
signEvent; cifrar y descifrar son opcionales, y una aplicación que los da por sentados
falla en silencio contra un firmante mínimo. Conviene probar con otro firmante antes de
suponer que la aplicación está rota.
El firmante remoto nunca recibe la solicitud. El tráfico de NIP-46 viaja por un relé, así
que los dos lados tienen que compartir uno que funcione. Comprobar que el relé nombrado en la
cadena bunker:// o nostrconnect:// es alcanzable, y probar con otro.
La nota no aparece en otros clientes. Lo más probable es que se esté publicando en relés que nadie más lee. Es un problema de selección de relés y no de inicio de sesión, y la firma estuvo bien.
Se pegó el nsec en un lugar donde no correspondía. Conviene dar esa identidad por
comprometida de forma permanente. Generar una clave nueva, avisar a través de la anterior
mientras todavía esté bajo control propio, y aceptar la pérdida del grafo de seguidores. No
hay procedimiento de recuperación, y quien ofrezca uno está montando una estafa.
Corrección, 20 de agosto de 2026. Una versión anterior de este artículo describía la firma remota de NIP-46 como experimental y decía que las extensiones de navegador no estaban admitidas en navegadores móviles. NIP-46 es una especificación asentada con firmantes en producción, y Firefox para Android admite firmantes como extensión. Las dos afirmaciones fueron corregidas, y la guía ahora dice que una clave de Nostr no se puede rotar, algo que la versión anterior omitía.