Lee eventos reales de relays públicos. Nunca publicamos nada.
Tema
Idioma
99 NIPs
Referencia de NIPs
Todos los NIPs en un solo lugar. Busca por significado o por palabra clave, filtra por estado y abre cualquier NIP para editar el JSON que define y ver qué hace cada campo.
Los resultados por palabra clave son instantáneos. Cuando empiezas a escribir, se carga en tu dispositivo (una sola vez) un pequeño modelo de búsqueda para buscar también por significado.
El núcleo de Nostr: un único objeto JSON firmado llamado evento, y el puñado de mensajes que clientes y relays intercambian por un WebSocket para publicar eventos y suscribirse a ellos.
El kind 3 es tu lista de seguidos: un tag p por cada persona que sigues, con una pista de relay opcional y un apodo local (petname). Publicar una nueva reemplaza la anterior.
El kind 1040 lleva una prueba OpenTimestamps de que un evento existía antes de cierto bloque de Bitcoin. Marcado como no recomendado en el repositorio oficial: es vulnerable a un ataque concreto y está pendiente de actualización.
El DM cifrado original: kind 4 con content en AES-CBC dirigido a un tag p. Obsoleto en favor de NIP-17 porque revela quién habla con quién y usa criptografía débil.
Te permite mostrar un nombre parecido a un email, como alice@alpha.example: el dominio sirve /.well-known/nostr.json, que asocia nombres a claves públicas, y los clientes comprueban que coincida.
Deriva claves de Nostr a partir de una frase semilla BIP-39 por la ruta m/44'/1237'/<cuenta>'/0/0. No recomendado en el repositorio oficial: es preferible manejar una sola nsec.
Una extensión del navegador expone window.nostr para que los sitios web puedan obtener tu clave pública, firmar eventos y cifrar mensajes sin ver nunca tu clave secreta.
La forma antigua de mencionar personas y notas: sustituir la mención por #[índice], que apunta al array de tags. Obsoleto en favor de las URIs nostr: de NIP-27.
El kind 5 pide a relays y clientes que borren eventos anteriores tuyos, referenciados con tags e o a. Es una solicitud: nada puede garantizar el borrado en todas partes.
El kind 1 es la nota de texto plano. Los tags e marcados (root, reply) forman hilos, los tags p notifican a todos los participantes de la conversación y los tags q citan eventos.
Los relays se describen a sí mismos con un documento JSON servido por HTTP en su URL de WebSocket: nombre, contacto del administrador, NIPs soportados, límites y tarifas.
Gasta CPU para que el id de un evento empiece con bits a cero. Un tag nonce registra el contador y el objetivo comprometido, para que los relays puedan exigir una dificultad mínima contra el spam.
Puestos, productos, subastas y mensajes de compra NIP-04 para tiendas descentralizadas. No recomendado en el repositorio oficial por ser demasiado complicado: usa los anuncios clasificados de NIP-99 en su lugar.
Chats privados que ocultan quién habla con quién: los mensajes son rumores sin firmar, sellados con NIP-44 por el remitente y envueltos en un gift wrap con una clave desechable hacia los relays de DM de cada participante.
Comparte el evento de otra persona con tus seguidores: el kind 6 hace repost de una nota de texto, el kind 16 de cualquier otra cosa, y los tags q convierten una mención en una publicación con cita.
Strings fáciles de leer como npub1…, nsec1… y nevent1… para mostrar y compartir claves, ids y punteros. Solo para mostrar e introducir datos: los eventos y filtros siempre usan hex.
Pon "nostr:" delante de un código NIP-19 (npub, nprofile, note, nevent, naddr) y obtienes un enlace que cualquier app de Nostr puede abrir, dentro de notas, en páginas web o en códigos QR.
Comentarios kind 1111: un hilo de respuestas que puedes colgar de cualquier cosa, un artículo, un archivo, un episodio de podcast o una URL web, usando tags en mayúscula para la raíz y en minúscula para el padre.
Artículos y entradas de blog como kind 30023: contenido Markdown más tags de título, resumen, imagen y hashtags. Cada artículo tiene un tag d, así que puedes editarlo y los enlaces siguen apuntando a la última versión.
Un catálogo de extras muy usados que ningún otro NIP define: campos de perfil como display_name, website, banner, bot y birthday, más los tags genéricos r, i, title y t.
Me gusta, no me gusta y reacciones con emoji como eventos kind 7 que apuntan a la nota a la que reaccionaste. "+" es un me gusta, "-" un no me gusta y cualquier otra cosa un emoji. El kind 17 hace lo mismo para páginas web y otras cosas fuera de Nostr.
No recomendado: usa la firma remota de NIP-46 en su lugar. Permite que una clave publique en nombre de otra mediante un tag de delegación firmado, limitado por kind y ventana de tiempo.
Cómo mencionar personas y citar eventos dentro del texto de una nota: escribe enlaces nostr: en el content y añade tags p o q cuando quieras notificar a la persona o que la cita cuente.
No recomendado: usa los grupos basados en relays de NIP-29 en su lugar. Canales de chat abiertos construidos con cinco kinds: crear un canal (40), actualizar su información (41), publicar mensajes (42) y ocultar mensajes (43) o silenciar usuarios (44) para ti.
Grupos cerrados o abiertos que un relay hace cumplir: los miembros publican con un tag h, los administradores gestionan el grupo con los kinds 9000–9020 y el relay publica los metadatos, administradores y miembros del grupo como kinds 39000–39005.
Usa tus propias imágenes como emoji: escribe :shortcode: en el texto y añade un tag emoji que asocie el shortcode a una URL de imagen. Funciona en perfiles, notas, comentarios, reacciones y estados.
No recomendado, aunque los tags alt siguen siendo comunes. Da a los eventos de kinds personalizados un tag alt con una descripción legible de una línea, para que los clientes que no conocen el kind puedan mostrar algo sensato.
Asocia etiquetas a eventos, personas, relays, URLs o temas con el kind 1985: un tag L nombra el vocabulario y los tags l llevan las etiquetas. Los autores también pueden etiquetar sus propios eventos. Se usa para moderación, licencias, idiomas y clasificación.
Obsoleto: renombrados como "eventos direccionables" y trasladados a NIP-01. Los kinds 30000–39999 se reemplazan por autor y tag d, así que gana la versión más reciente y una dirección siempre la encuentra.
Colaboración en código sobre Nostr: anuncia repositorios git, publica el estado de sus ramas y envía parches, pull requests, issues y actualizaciones de estado como eventos, sin una forja central.
Un índice de torrents buscable en Nostr: el kind 2003 enumera el info hash, los archivos, los trackers y los ids de catálogo (IMDb, TMDB…) de un torrent para que cualquiera pueda construir el enlace magnet. En Nostr no se guardan archivos torrent.
Añade un tag content-warning, con un motivo opcional, y los clientes ocultan el evento tras un botón "mostrar de todos modos" hasta que el lector decida verlo.
Guarda publicaciones sin terminar de cualquier kind en relays sin que nadie más las lea: el borrador se cifra para ti mismo con NIP-44 dentro de un envoltorio kind 31234, con checkpoints opcionales y una lista de relays privados.
Comparte un estado en vivo junto a tu nombre, como lo que estás haciendo o la canción que suena, como un evento kind 30315 que puede caducar por sí solo.
Demuestra que también controlas cuentas en otros sitios (GitHub, Mastodon, Bluesky, Telegram, Discord…): enuméralas en un evento kind 10011, cada una apuntando a una publicación pública donde esa cuenta menciona tu npub.
Añade un tag expiration para que un evento pueda indicar cuándo deja de ser relevante. Los relays compatibles dejan de servirlo a partir de ese momento y los clientes lo ocultan, algo ideal para avisos temporales y ofertas por tiempo limitado.
Permite que un relay pregunte "¿quién eres?" antes de servir o aceptar eventos. El relay envía un desafío, el cliente firma un evento kind 22242 de corta vida que lo repite, y así el relay sabe qué pubkey está al otro lado de la conexión.
Da a los relays de membresía un vocabulario común: el relay publica quiénes son sus miembros y qué roles existen, los usuarios piden unirse con un código de invitación o piden salir, y el relay anuncia cada cambio como un evento firmado.
El formato de cifrado que Nostr usa hoy: dos claves acuerdan un secreto compartido, el texto se rellena para ocultar su longitud, se cifra con ChaCha20, se autentica con HMAC-SHA256 y se empaqueta en un único string base64 con un byte de versión. No define ningún kind de evento; otros NIPs ponen el resultado en el content de un evento.
Añade un verbo COUNT para que un cliente pueda preguntar a un relay "¿cuántos eventos coinciden?" en lugar de descargarlos todos. Los relays pueden devolver un número aproximado y un sketch HyperLogLog que los clientes pueden combinar entre relays.
Mantiene tu clave secreta en un único lugar, un "bunker", y permite que las apps le pidan firmar. La app y el bunker se comunican mediante eventos kind 24133 cifrados en relays, con solicitudes al estilo JSON-RPC como sign_event, get_public_key y nip44_encrypt.
Permite que una app pague y cree facturas Lightning a través de tu wallet sin custodiar tus fondos. La wallet le da a la app una URI de conexión; luego la app envía solicitudes cifradas como pay_invoice por relays y recibe resultados cifrados.
Marca los eventos que un puente (bridge) copió a Nostr desde ActivityPub, Bluesky, RSS o la web. Un tag proxy apunta al objeto original, para que los clientes puedan enlazarlo y no mostrar la misma publicación dos veces.
Define ncryptsec, una forma de clave secreta protegida con contraseña. La contraseña se refuerza con scrypt, la clave se cifra con XChaCha20-Poly1305 y el resultado es un string bech32 que empieza por ncryptsec1, seguro para copias de seguridad pero no para publicarlo.
Añade un campo search a los filtros REQ para que los clientes puedan pedir a los relays resultados de búsqueda de texto completo, como "mejores apps de nostr". Los relays ordenan los resultados por relevancia en lugar de por fecha y pueden soportar opciones clave:valor extra como language:en.
Una familia de eventos de lista: listas estándar, una por usuario (silenciados, fijados, marcadores, relays de búsqueda…), y conjuntos con nombre de los que puedes tener muchos (conjuntos de seguidos, de curación, de relays…). Los elementos van en los tags cuando son públicos, o en el content cifrado cuando son privados.
Entradas de calendario como eventos Nostr: eventos de día completo por fecha, eventos con hora y zona horaria, calendarios que los agrupan y RSVPs en los que la gente responde accepted, declined o tentative. Los eventos recurrentes se dejan fuera a propósito.
Describe transmisiones en vivo y salas de audio/video como eventos que se actualizan mientras ocurren: quién presenta, dónde verlo, cuánta gente hay dentro. Los espectadores chatean con mensajes kind 1311, y los oyentes de una sala indican su presencia y si levantan la mano.
Una enciclopedia abierta donde cualquiera puede escribir un artículo sobre cualquier tema. Los artículos son eventos direccionables kind 30818 en Djot, muchos autores pueden cubrir el mismo tema y los lectores eligen versiones mediante reacciones, seguidos y relays de confianza. Los forks, las solicitudes de fusión y las redirecciones también son eventos.
Permite que las apps de Android (y las páginas web abiertas en Android) pidan a una app firmante separada que firme eventos y cifre o descifre mensajes, para que solo el firmante tenga la clave secreta. Las solicitudes pasan por intents, un content resolver en segundo plano o enlaces nostrsigner:.
Un reporte kind 1984 señala un perfil, una nota o un archivo multimedia como inapropiado, con un tipo como spam, suplantación o malware. Cualquiera puede leer los reportes; clientes y relays deciden por su cuenta si actuar, normalmente confiando en reportes de la gente a la que sigues.
Los zaps son propinas Lightning registradas en Nostr. El emisor firma una solicitud de zap y se la entrega a la wallet Lightning del destinatario en lugar de publicarla; una vez pagada la factura, la wallet publica un recibo de zap para que todos vean quién hizo zap a qué.
Cualquiera puede diseñar una insignia y otorgarla a otras personas. Las concesiones son permanentes y no se pueden transferir, pero cada destinatario elige qué insignias mostrar en su perfil y en qué orden, y puede agruparlas en conjuntos.
Oculta quién habla con quién anidando un evento en dos sobres cifrados. Un rumor sin firmar va dentro de un seal firmado por el autor real, y el seal va dentro de un gift wrap firmado por una clave desechable, así los relays solo ven un emisor aleatorio y al destinatario.
Aloja un sitio web estático en Nostr: un manifiesto firmado asocia cada ruta de archivo con el sha256 de un blob en servidores Blossom, y un servidor anfitrión lo convierte en un sitio web normal.
Las notas de kind 64 llevan partidas de ajedrez en PGN, el formato de texto plano que ya lee el software de ajedrez, para que los clientes puedan dibujar el tablero.
Los monitores sondean relays y publican lo que encuentran (disponibilidad, velocidad, NIPs soportados, reglas), para que los clientes descubran relays y eviten los caídos.
Los relays pueden añadir a EOSE una pista que indica si enviaron todas las coincidencias almacenadas o si hay más, para que los clientes sepan cuándo dejar de paginar.
Las publicaciones de kind 20 giran en torno a fotos, al estilo de Instagram: imágenes alojadas en otro sitio y descritas en tags imeta, con un pie de foto como contenido.
Un formato común para ofertas de compra y venta de bitcoin, para que las plataformas de intercambio P2P publiquen en un único libro de órdenes público en lugar de en silos separados.
Publicaciones de video dedicadas para clientes al estilo de YouTube o TikTok: horizontales (kind 21) o cortos verticales (kind 22), con cada resolución y pista de audio listada en tags imeta.
Comunidades al estilo de Reddit donde los moderadores aprueban las publicaciones. Ya no se recomienda: los proyectos nuevos deberían usar los grupos basados en relays de NIP-29.
Los tags i y k hacen que los eventos de Nostr apunten a cosas fuera de Nostr (libros, páginas web, podcasts, lugares, transacciones de blockchain) para que puedas encontrar todos los comentarios sobre ellas.
Una meta de recaudación como evento de kind 9041: una cantidad objetivo y los relays donde se cuentan los zaps. Haz zap a la meta para contribuir y mira cómo se llena la barra de progreso.
Una forma de que un cliente y un relay (o dos relays) averigüen qué eventos le faltan a cada uno intercambiando huellas compactas en lugar de listas completas de ids.
Permite a las apps guardar sus propios datos privados, como ajustes, en tus relays y en el formato que quieran, como kind 30078 (un registro por clave) o kind 78 (muchos registros).
Permite que cálculos pesados, como puntuaciones de red de confianza o recuentos de seguidores, se hagan en un servicio que tú eliges, que publica los resultados como eventos firmados que tu cliente simplemente lee.
Una API HTTP, en la misma dirección que el WebSocket del relay, que permite a su operador vetar pubkeys, permitir kinds y moderar eventos con llamadas JSON-RPC sencillas firmadas mediante NIP-98.
Las mints de ecash se anuncian con un evento y la gente recomienda las mints en las que confía, así un monedero puede encontrar una mint a través de las personas que sigues.
Una encuesta es un evento kind 1068 con una pregunta y opciones; cada voto es un evento kind 1018 enviado a los relays que indica la encuesta, y los clientes cuentan un voto por persona.
Cuando tu app encuentra un kind de evento que no sabe mostrar, puede buscar una app que sí sepa: las apps anuncian qué kinds manejan (31990) y la gente las recomienda (31989).
Un mercado de computación de pago sobre nostr: publicas un trabajo (traducir, resumir…), los servicios compiten por hacerlo y publican el resultado. Ya no se recomienda: se prefieren especificaciones más pequeñas para casos de uso concretos.
Cuando una nota enlaza una imagen o un video, una etiqueta imeta describe ese archivo (tipo, tamaño, dimensiones, hash, texto alternativo) para que los clientes muestren una buena vista previa antes de descargarlo.
El kind 1063 describe un archivo compartido (dónde descargarlo, su tipo, hash, tamaño y vistas previas) para que las apps de intercambio de archivos puedan indexarlos y filtrarlos en los relays.
Una API REST para subir archivos a servidores de almacenamiento con autenticación de nostr y luego enlazarlos en notas. Ya no se recomienda: usa Blossom (NIP-B7) en las apps nuevas.
Inicia sesión en una API HTTP con tu clave de nostr: firma un evento kind 27235 de corta duración que indique la URL y el método exactos, y envíalo en la cabecera Authorization.
El kind 30402 es un anuncio clasificado: algo en venta, en alquiler o gratis, escrito en Markdown con título, precio, ubicación e imágenes, y editable porque es direccionable.
Notas de voz cortas de hasta un minuto aproximadamente: kind 1222 para un mensaje nuevo y kind 1244 para una respuesta de voz, cada uno apuntando a un archivo de audio.
Una lista kind 10133 de las formas en que pueden pagarte, como Bitcoin, Lightning o PayPal, cada una escrita como un tag payto con un tipo y una dirección.
El kind 24 es un mensaje público corto dirigido a una o más personas, que se muestra en sus notificaciones en lugar de en los feeds, sin hilos y sin privacidad.
Usa servidores Blossom para multimedia: los archivos se guardan y se encuentran por su hash sha256, y tu lista de servidores kind 10063 indica a los demás dónde buscar cuando un enlace deja de funcionar.
No recomendado. Dos dispositivos cercanos sincronizan eventos de Nostr por Bluetooth Low Energy sin internet: uno actúa como relay y el otro como cliente, usando NIP-77 para averiguar qué falta.
Comparte código como eventos kind 1337: el content es el código, y los tags indican el lenguaje, el nombre de archivo, la licencia, las dependencias y el repositorio de origen.
El kind 9 es un mensaje de chat. Para responder, envía otro kind 9 que cite el mensaje anterior con un tag q, así los chats siguen siendo un flujo ordenado y simple.
Geocaching en Nostr: esconde un cache como un listado kind 37516, registra hallazgos como kind 7516, demuestra que estuviste allí con un evento kind 7517 firmado con la propia clave del cache, y agrupa caches en rutas.
No recomendado, reemplazado por el protocolo Marmot. Definía chats directos y de grupo cifrados de extremo a extremo en Nostr usando MLS (RFC 9420), con secreto hacia adelante y seguridad poscompromiso.
Podcasts como feeds de Nostr: cada programa tiene su propio par de claves, publica la información del programa en kind 10154 y un evento kind 54 por episodio, y los presentadores confirman su autoría con kind 10164.