Tu identidad: claves, perfil y dispositivos

En la mayoría de las herramientas de trabajo tu identidad es una fila en la base de datos de alguien: un correo, una contraseña y una sesión que el servidor te concede o te revoca. En Buzz no. Tu identidad es un par de claves criptográficas que generaste tú y que vive en tu máquina. El relay no te la dio y no puede quitártela: solo puede decidir si te deja entrar.

Esa diferencia cambia cosas que vas a notar todos los días: cómo inicias sesión, qué significa “editar el perfil”, cómo llevas tu cuenta a un segundo dispositivo y qué pasa exactamente si pierdes la clave. Si vienes del capítulo anterior ya tienes el cliente instalado y una identidad creada. Aquí la miramos por dentro.

Un par de claves, dos representaciones

Tu identidad es un par de claves secp256k1, las mismas que usa Bitcoin para firmar. La documentación del CLI de Buzz lo dice sin rodeos: the keypair IS the identity — no tokens, no other auth. No hay sesiones, no hay tokens de acceso, no hay “olvidé mi contraseña”.

• Clave privada (nsec): es el secreto. Firma. Nunca sale de tus dispositivos, nunca se pega en un chat, nunca se sube a un repositorio.
• Clave pública (npub): es tu dirección. Se deriva de la privada, es pública por diseño y es lo que otras personas usan para mencionarte, abrirte un DM o añadirte a un canal.

flowchart LR
    S["Clave privada<br/>nsec1... / hex de 64 chars"] -->|"derivación"| P["Clave pública<br/>npub1... / hex de 64 chars"]
    S -->|"firma Schnorr"| E["Cada evento que publicas"]
    P -->|"verificación"| E
    P --> D["Tu dirección: menciones, DMs, membresía"]

La derivación va en un solo sentido. De la privada sale la pública; de la pública no sale nada. Por eso puedes publicar tu npub en tu firma de correo sin riesgo, y por eso perder el nsec es irreversible.

bech32 y hex: la misma clave, dos vestidos

Formato	Aspecto	Para qué se usa
bech32	npub1…, nsec1…	Legible por humanos. El prefijo delata a simple vista si es pública o privada, e incluye checksum: una letra mal copiada se detecta
hex	64 caracteres 0-9a-f	Formato de cable. Es lo que viaja dentro de los eventos Nostr y lo que casi todos los flags del CLI esperan

La regla mental: bech32 es para pegar, hex es para máquinas. El prefijo nsec1 existe precisamente para que un humano note que está mirando un secreto antes de compartirlo por error. Dónde acepta Buzz cada uno, según el código:

Superficie	Formato aceptado
BUZZ_PRIVATE_KEY / --private-key	hex o nsec1…
--pubkey en users get, dms open, channels add-member	hex de 64 caracteres, validado estrictamente
--mention en messages send	hex o npub
--author en messages search	hex, npub o nombre
--owner en users get --name	me, hex o npub
Filtro npub en plantillas de workflow	convierte una pubkey hex a npub completo

Ese último detalle esconde una decisión de seguridad: existe un filtro heredado llamado truncate_pubkey que es alias de npub y no trunca nada, porque los prefijos truncados de pubkey son grindables — alguien puede fabricar una clave cuyos primeros caracteres coincidan con los tuyos.

Cada cosa que haces va firmada

Esto es lo que hace que la auditoría en Buzz sea distinta. No hay un servidor que “registra que tú hiciste algo”: eres tú quien firma cada acción, y cualquiera puede verificar la firma sin confiar en el servidor.

sequenceDiagram
    participant T as Tu cliente
    participant K as Tu clave privada
    participant R as Relay
    participant O as Otro miembro

    T->>T: Construye el evento con kind, tags y contenido
    T->>T: Calcula el id como SHA-256 de la serialización canónica
    T->>K: Firma el id
    K-->>T: Firma Schnorr
    T->>R: EVENT con id, pubkey, sig
    R->>R: Verifica firma e id antes de almacenar
    R->>R: Anota la acción en la cadena de auditoría
    R->>O: Reenvía el evento firmado
    O->>O: Vuelve a verificar la firma por su cuenta

Tres consecuencias que se notan en el uso diario:

1. El relay no puede hablar por ti. Puede rechazar tus eventos, pero no fabricar uno con tu pubkey. Verifica la firma Schnorr y recalcula el id como SHA-256 de la serialización canónica, de forma independiente, antes de almacenar cualquier evento.
2. Editar o borrar deja rastro. Editar publica un evento nuevo; borrar publica una solicitud NIP-09 que solo el autor puede firmar sobre sus propios eventos. El historial no se reescribe en silencio.
3. Existe una bitácora encadenada. Cada entrada de auditoría incluye el hash de la anterior, partiendo de un hash génesis de 64 ceros, y cubre acciones como EventCreated, EventDeleted, ChannelCreated, MemberAdded, MemberRemoved, AuthSuccess y AuthFailure. Alterar una entrada rompe todos los hashes siguientes.

Dos exclusiones deliberadas: los eventos de autenticación NIP-42 (kind 22242) nunca se almacenan ni se registran en la cadena de auditoría, y los eventos efímeros del rango 20000–29999 tampoco. Tu presencia y tu “está escribiendo…” no dejan huella permanente. La operación y verificación de esa cadena es asunto de quien administra el servidor: está en el curso de administrador.

Cuando falta la clave

Si usas el CLI sin clave, el error es explícito y el código de salida es 3. Si la clave está pero no parsea, la categoría cambia a key_error, también con salida 3:

$ buzz channels list
{"error":"auth_error","message":"auth error: BUZZ_PRIVATE_KEY is required (use --private-key or set env var)","retryable":false}

La única excepción es el grupo pack, que corre en local, no habla con el relay y por eso se ejecuta antes de que se exija la clave.

Dónde vive tu clave

El cliente de escritorio resuelve la identidad en un orden fijo al arrancar: variable de entorno BUZZ_PRIVATE_KEY → llavero del sistema → archivo identity.key en el directorio de datos de la app → generar una nueva y guardarla. El estado resultante se reporta como uno de cuatro valores: system-keyring, local-file, environment o ephemeral.

stateDiagram-v2
    [*] --> Arranque
    Arranque --> Normal: BUZZ_PRIVATE_KEY válida
    Arranque --> Llavero: sin variable de entorno
    Llavero --> Normal: clave encontrada
    Llavero --> Archivo: llavero vacío y sin marcador de migración
    Archivo --> Normal: identity.key encontrado o se genera uno nuevo
    Llavero --> Perdida: llavero vacío pero hubo migración previa
    Llavero --> Bloqueada: llavero inalcanzable esta sesión
    Perdida --> [*]: reimportar el nsec
    Bloqueada --> [*]: desbloquear el llavero y relanzar

Los dos estados de recuperación no son lo mismo y la app los distingue:

• Identidad perdida (lost): el llavero está vacío pese a que hubo una migración exitosa antes. La clave desapareció del sistema. La app arranca con una clave efímera y te encamina a reimportar tu nsec.
• Llavero bloqueado (locked): la clave sigue en el llavero, pero no es alcanzable en esta sesión — típico en Linux con GNOME Keyring o KWallet cerrados. No hay recuperación dentro de la app: hay que desbloquear el llavero fuera y relanzar Buzz. La pantalla lo dice tal cual: Your identity is safe in the OS keyring, but it’s unreachable this session.

En ambos casos la firma queda deshabilitada a propósito, con el error identity is in recovery mode; event signing is disabled until the identity is restored and Buzz is relaunched. Buzz prefiere no publicar nada antes que publicar bajo una identidad equivocada.

Tu perfil: metadatos, no cuenta

Tu perfil es un evento Nostr de kind 0 con metadatos en JSON. Lo firmas tú, como todo lo demás, y el relay lo sincroniza a su tabla de usuarios para poder mostrar nombres y avatares.

Desde la terminal:

buzz users get                                # tu propio perfil
buzz users get --pubkey 3bf0c63f...           # el de otra persona
buzz users get --pubkey <hex> --pubkey <hex>  # batch, máximo 200 por llamada

buzz users set-profile \
  --name "Ana Rivas" \
  --about "Backend. Café. Rust." \
  --avatar "https://mi-relay.example.com/media/abc123.png" \
  --nip05 "[email protected]"

Los cuatro campos que acepta set-profile son exactamente --name, --avatar, --about y --nip05. No hay más. En el escritorio, la tarjeta de perfil en Ajustes expone lo mismo con otros nombres visibles: Display name, Profile description, el avatar, y muestra en solo lectura tu Public key y tu NIP-05 handle.

La regla del NIP-05 que sorprende a todo el mundo

NIP-05 es el “handle” con forma de correo ([email protected]) que sirve para que te encuentren por un nombre humano. Buzz tiene una regla dura aquí:

Los handles NIP-05 deben canonicalizar al dominio de este relay. Los que apuntan fuera del dominio, o los inválidos, se limpian silenciosamente.

Puedes escribir lo que quieras en --nip05, pero si no corresponde al dominio del relay al que estás conectado, el campo queda vacío sin error ni aviso. Y si tu handle choca con el de otra persona —hay una restricción de unicidad— el handle se salta pero el resto de los campos sí se sincronizan: vas a ver tu nombre y avatar actualizados y el handle en blanco.

Perfil por comunidad, clave global

Tu par de claves es tuyo en todas las comunidades; tu perfil, tus DMs y el contenido sin canal viven por comunidad. Republicas tu perfil en cada comunidad a la que entras.

La URL es la comunidad. Si entras a un segundo workspace Buzz con la misma clave, serás la misma persona criptográficamente, pero tu nombre, avatar y conversaciones no viajan solos. Los DMs tampoco cruzan dominios.

Presencia y estado

Son dos cosas distintas y se confunden seguido.

Presencia es el semáforo de disponibilidad. Es un evento efímero de kind 20001: no se almacena, no se audita, se escribe en Redis y se reparte a las suscripciones activas. Los tres valores aceptados son los únicos que existen, y offline no es uno más: dispara la limpieza de la entrada en Redis en vez de escribir una nueva. La cadena de estado se trunca a 128 caracteres.

buzz users set-presence --status online          # o away, u offline
buzz users presence --pubkeys <hex64>,<hex64>    # consultar a otras personas

Estado es la frase que acompaña tu nombre, tipo “en un huddle” o “sin notificaciones hasta el lunes”. Es un evento NIP-38 de kind 30315, este sí persistente:

buzz users set-status --text "heads down on the CLI" --emoji "🚀"
buzz users set-status --clear

--clear es incompatible con --text y con --emoji: o pones un estado o lo quitas. Y --emoji por sí solo no basta, hace falta el texto. En el escritorio esto vive en el diálogo Set status.

Hay un tercer evento relacionado con dispositivos que no configuras a mano pero conviene conocer: el estado de lectura (kind 30078), que sincroniza hasta dónde leíste cada canal entre tus dispositivos. Su contenido va cifrado con NIP-44 hacia tu propio par de claves, así que ni el relay ni nadie más sabe qué leíste.

Un segundo dispositivo: emparejamiento NIP-AB

El problema real: quieres Buzz en el móvil o en un segundo equipo, y la única forma de ser “tú” ahí es que ese dispositivo tenga tu clave privada. Las opciones malas son pegar el nsec por chat o dictarlo en voz alta. Buzz implementa un protocolo para hacerlo bien: NIP-AB, Device Pairing. El spec es claro sobre qué resuelve: NIP-46 resuelve la delegación continua —la clave se queda en un dispositivo y firma en remoto—, mientras que NIP-AB resuelve la transferencia única: la clave se mueve al dispositivo nuevo, que a partir de ahí opera solo.

Cómo funciona

sequenceDiagram
    participant S as Dispositivo origen
    participant R as Relay de emparejamiento
    participant T as Dispositivo destino

    S->>S: Genera par efímero y secreto de sesión de 32 bytes
    S->>T: Muestra QR con pubkey efímera, secreto y relay
    T->>T: Escanea el QR y genera su propio par efímero
    T->>R: Envía offer con el session_id derivado
    R->>S: Entrega el offer
    Note over S,T: Ambas pantallas muestran los mismos seis dígitos
    S->>R: sas-confirm con el hash de transcripción
    R->>T: Entrega el sas-confirm y el destino lo verifica
    S->>R: payload cifrado con NIP-44 v2
    R->>T: Entrega el payload
    T->>T: Descifra e importa la identidad
    T->>R: complete
    R->>S: Entrega el complete

Las piezas concretas, tal como están implementadas:

• Kind del evento: 24134, dentro del rango efímero. El relay puede descartarlos tras entregarlos.
• URI del QR: nostrpair://<pubkey_efimera_hex>?secret=<hex>&relay=<url>&v=1. Pubkey y secreto son 64 caracteres hex en minúsculas cada uno, el relay va percent-encoded y la URI completa no puede pasar de 2048 caracteres. Nunca contiene material de clave privada: quien la intercepte obtiene una pubkey efímera y un secreto de sesión, inútiles sin completar el intercambio a tiempo.
• SAS: los seis dígitos que ves en ambas pantallas. Es la defensa contra un intermediario: si alguien se metió en medio, los códigos no coinciden.
• Cifrado: NIP-44 versión 2 obligatoria. El relay solo ve ciphertext opaco entre dos pubkeys desechables sin relación con ninguna identidad real.
• Tipos de payload: nsec, bunker, connect o custom. bunker lleva una URI bunker:// y connect una nostrconnect://, ambas de NIP-46: el mismo canal puede transferir la clave cruda o arrancar una sesión de firma remota. El texto plano serializado de un custom está sujeto al límite general de 65 535 bytes.
• Razones de aborto: sas_mismatch, user_denied, timeout, protocol_error.

Si el destino detecta que el hash de transcripción no cuadra, el spec obliga a abortar con sas_mismatch, y la herramienta de referencia lo reporta como SECURITY: transcript hash mismatch — possible MITM attack. Session aborted. No es un error recuperable.

En el escritorio

La aplicación de escritorio trae esto integrado en Ajustes, con tres pasos numerados: Scan QR code — Open Buzz on your mobile device and scan the code shown here; Confirm mobile code — Check that the six-digit code matches on both devices, then confirm it; y Pair your mobile app, que al terminar cambia a Paired.

El código se muestra agrupado en dos bloques de tres dígitos.

Existe también el camino inverso: si estrenas equipo y ya tienes Buzz funcionando en otro, la pantalla de recuperación de identidad usa el mismo emparejamiento para traer tu clave en vez de pedirte el nsec a mano. Ahí el QR se refresca cada 90 segundos, deliberadamente por debajo del tope de dos minutos de conexión del relay de emparejamiento, para que nunca quede en pantalla un código cuyo canal ya se cerró. Si el emparejamiento expira, el mensaje es literal: This pairing code expired or lost its connection. Create a new code and try again.

Nota de estado real: según la tabla del README de Buzz, los clientes móviles para iOS y Android están en la columna Being wired up, no en Works today. El protocolo de emparejamiento existe y está implementado; la app móvil del otro lado todavía se está terminando. El capítulo Otros clientes: Nostr de terceros y móvil entra en detalle.

Las herramientas de línea de comandos

Hay dos binarios separados, y no son lo mismo:

buzz-pair (crate buzz-pairing-cli) ejercita el protocolo de punta a punta. Su propio README aclara que está pensada para pruebas de interoperabilidad y para la presentación del NIP, no para uso en producción:

# Terminal 1 — el lado que tiene el secreto
buzz-pair source --relay wss://relay.damus.io

# Terminal 2 — el lado que lo recibe; pega ahí la URI nostrpair://
buzz-pair target --show-secret

source acepta --relay (por defecto wss://relay.damus.io) y --nsec con la clave bech32 a transferir; sin --nsec genera una clave de prueba desechable. target acepta --relay para sobreescribir el relay del QR y --show-secret, apagado por defecto. Un tercer subcomando, test-vectors, imprime los valores criptográficos derivados de las claves fijas del spec.

buzz-pair-relay es otra cosa: un relay lateral efímero que solo routea handshakes de emparejamiento. No persiste nada, no tiene autenticación y no guarda historial; verifica firmas Schnorr, empareja eventos kind 24134 contra suscripciones filtradas por p y los reenvía. Sus límites están en el código: 128 conexiones WebSocket, tramas de 4 KiB, 120 segundos de vida por conexión, 6 eventos aceptados por conexión, tolerancia de ±120 segundos en created_at y deduplicación de ids durante 300 segundos. Escucha en 127.0.0.1:5000 por defecto, configurable con BUZZ_PAIR_RELAY_BIND_ADDR, y debe correr detrás de un proxy inverso que solo enrute /pair y termine TLS. Ese despliegue es trabajo de operador: va en el curso de administrador.

Si pierdes la clave

Sin rodeos: no hay recuperación. No existe un botón de “restablecer contraseña” porque no hay contraseña y no hay nadie con autoridad para reasignarte tu identidad. Si tu nsec desaparece y no tienes copia, esa identidad se acabó.

Lo que se pierde y lo que no:

Se pierde	Se conserva
La capacidad de firmar como esa pubkey	Todo lo que ya publicaste, atribuido a esa pubkey
El acceso a tus DMs cifrados hacia ti	Los canales, con su historial, para el resto del equipo
El control de los agentes que gestionabas con esa clave	La cadena de auditoría, intacta

Empiezas de cero con una clave nueva: nueva pubkey, nuevo perfil, y el operador del workspace tiene que volver a darte de alta en la comunidad y en los canales privados. El spec de archivado de identidades explica por qué las solicitudes de borrado no sirven aquí: no ayudan cuando la clave antigua se perdió, y son demasiado destructivas para una rotación normal de clave: los mensajes antiguos de David deben seguir atribuidos a la pubkey antigua de David.

Rotar una clave, de forma ordenada

Cuando la rotación es planificada —cambias de clave, se va un contratista, se reconstruye un bot— existe el archivado de identidad (NIP-IA). Archivar una pubkey le pide al relay que la esconda de los listados de miembros activos, autocompletados y selectores, sin borrar ningún evento y sin implicar ninguna reputación global: un archivo hecho en el relay A vale solo para el relay A. Tiene además una propiedad deliberada contra los shadowbans: la persona archivada siempre se ve a sí misma, así que puede notarlo y pedir el desarchivado.

Copias de seguridad: el formato NIP-49

El escritorio incluye un flujo de respaldo cifrado que no depende de que copies el nsec a mano. En Ajustes, la fila Private key ofrece Reveal / Hide (muestra el nsec enmascarado, solo mientras la fila está expandida), Create backup, Test backup — Confirm that a backup file and its password can unlock an identity — y Download backup, con una ventana de disponibilidad limitada dibujada como una barra que se vacía.

El respaldo usa el formato estándar NIP-49 (ncryptsec), así que sirve también para respaldos de otras aplicaciones Nostr compatibles. La contraseña se deriva con scrypt y hay un generador de frases basado en la lista corta de la EFF con entropía del sistema operativo, entre 3 y 10 palabras y con separador elegible. El aviso literal del flujo: Keep the file private and save its password somewhere safe.

Probar el respaldo no es opcional en la práctica. Un archivo cifrado cuya contraseña no recuerdas es exactamente igual de útil que no tener respaldo.

Cerrar sesión borra la clave

La sección de cierre de sesión en Ajustes no es un “logout”. El texto lo advierte: Removes your identity key and all local app data from this device. Por eso está protegida por dos compuertas: confirmar que puedes recuperar la identidad —el diálogo muestra el nsec como último recurso y exige marcar una casilla— y escribir literalmente la frase wipe all my data. Solo con ambas se habilita el botón Delete my data. La comparación ignora mayúsculas y espacios sobrantes: la fricción buscada es el acto de escribirla.

Buenas prácticas de custodia

Cinco reglas que se derivan de todo lo anterior:

1. Haz el respaldo cifrado y pruébalo el mismo día. Create backup y luego Test backup, que existe justamente para eso.
2. Guarda el archivo y la contraseña en lugares distintos. Juntos no son un respaldo: son una copia del nsec.
3. Deja que el llavero del sistema haga su trabajo. system-keyring es el mejor de los cuatro estados de almacenamiento; local-file es aceptable; ephemeral significa que la clave desaparece al cerrar.
4. Usa BUZZ_PRIVATE_KEY con cuidado. Es cómoda para el CLI y para agentes, pero una variable de entorno acaba en el historial del shell, en logs de CI y en volcados de proceso. El CLI oculta su valor en la ayuda, pero eso no protege tu .zshrc.
5. Nunca pegues el nsec en un canal, ni siquiera en un DM contigo mismo. Para llevarlo a otro dispositivo está el emparejamiento NIP-AB.

Y una advertencia que el spec de emparejamiento pone por escrito: una vez transferida la clave, sus garantías terminan. Si el dispositivo destino se compromete después, la clave transferida está comprometida, y no hay revocación de un emparejamiento completado.

Tu identidad frente a la de un agente

Este es el punto que más confusión genera al empezar. Un agente no usa tu clave. Tiene su propio par de claves, su propia pubkey y su propio perfil, así que cuando publica un mensaje ese mensaje está firmado por él, no por ti. Su perfil vive en un evento de kind 10100 que incluye metadatos del agente y una referencia a su dueño.

flowchart TD
    U["Tu identidad<br/>tu par de claves"] -->|"firma la atestación"| A["Tag auth NIP-OA"]
    A -->|"viaja en los eventos del agente"| G["Identidad del agente<br/>par de claves propio"]
    G -->|"firma y es autor de"| M["Mensajes, patches y jobs del agente"]
    U -->|"firma y es autor de"| N["Tus mensajes"]

La pieza que conecta ambas identidades es la atestación de dueño (NIP-OA): un tag auth de exactamente cuatro elementos con la forma ["auth", "<owner-pubkey-hex>", "<conditions>", "<sig-hex>"]. Tú, como dueño, firmas con tu clave una autorización para que esa clave de agente publique bajo su propia autoría. El detalle importante, subrayado en el spec:

Un evento que incluye un tag auth válido sigue siendo autoría de event.pubkey.

Es decir, la atestación es evidencia de autorización, no suplantación: el agente no habla como tú, habla como él y lleva un certificado de que tú lo autorizaste. Las condiciones del tag pueden limitar el alcance con cláusulas kind=<decimal>, created_at<... o created_at>... unidas por &. En la práctica eso se traduce en la variable de entorno BUZZ_AUTH_TAG, que el CLI verifica criptográficamente contra la pubkey del firmante antes de usarla, y que es obligatoria para proponer o editar agentes:

# Sin BUZZ_AUTH_TAG, esto falla con:
# "agent draft requests require BUZZ_AUTH_TAG"
buzz agents draft-create \
  --channel <uuid> \
  --display-name "Honey" \
  --system-prompt "Revisa PRs y resume el diff en un párrafo"

Y sí, dice draft: el CLI propone un borrador que se abre como formulario prellenado en el escritorio del dueño, con un mensaje literal: Draft sent to Buzz Desktop for owner review. Nothing changes until the owner saves it. No existe un comando para crear agentes directamente desde la terminal.

Para encontrar y retirar a tus agentes:

buzz users get --name Honey --owner me            # buscar entre los tuyos
buzz agents archive <pubkey-hex> --reason rotated # retirar
buzz agents unarchive <pubkey-hex>
buzz agents archived                              # listado verificado

Los códigos de razón sugeridos son rotated, retired, bot-rebuilt, left-organization y spam, aunque acepta otros valores. El listado archived devuelve un snapshot firmado por el relay y verifica la autoría contra la clave que el relay anuncia, además del id, la firma y el marcado de evento protegido; cualquier fallo de confianza sale con código distinto de cero en vez de devolver datos dudosos.

Un último detalle relacionado: para apagar un agente de forma ordenada, su dueño envía un mensaje normal de kind 9 con el contenido !shutdown y una mención al agente. No hay comando ni botón secreto: es un mensaje firmado por ti, como todo lo demás.

Todo lo relativo a trabajar con agentes —qué hacen, cómo se les habla, cómo se revisa su trabajo— está en Agentes como compañeros de equipo.

Resumen

• Tu identidad es un par de claves secp256k1: el nsec firma y nunca se comparte; el npub es tu dirección. No hay tokens, sesiones ni recuperación de contraseña.
• La misma clave se escribe en bech32 (nsec1…, npub1…, con checksum) y en hex de 64 caracteres. La mayoría de los flags del CLI exigen hex; BUZZ_PRIVATE_KEY acepta ambos.
• Cada evento lleva tu firma Schnorr y un id que es SHA-256 de su serialización canónica; el relay verifica ambos antes de almacenar y anota la acción en una cadena de auditoría encadenada por hashes. Los eventos de autenticación y los efímeros quedan fuera de esa cadena por diseño.
• Tu perfil es un evento kind 0 que editas con buzz users set-profile --name --avatar --about --nip05. El handle NIP-05 debe canonicalizar al dominio del relay: si no, se descarta en silencio.
• Tu clave es global; tu perfil, tus DMs y el contenido sin canal viven por comunidad, y hay que republicar el perfil en cada una.
• Presencia (set-presence con online, away u offline) es efímera; estado (set-status --text --emoji, o --clear) es un evento NIP-38 persistente.
• Para un segundo dispositivo se usa NIP-AB: QR nostrpair:// con claves efímeras, código SAS de seis dígitos y payload cifrado con NIP-44 v2 sobre eventos kind 24134.
• Perder el nsec es irreversible: se pierde la capacidad de firmar, no el historial. Haz un respaldo cifrado NIP-49 y pruébalo.
• Un agente que tú gestionas tiene su propio par de claves y firma sus propios eventos; la atestación NIP-OA prueba que tú lo autorizaste sin transferirle tu autoría.

Siguiente: Canales y mensajes