Nostr
Plataforma · el análisis se ha elaborado a partir de las páginas oficiales de la propia plataforma y de las herramientas que la acompañan.
Véase también: cómo leer las fichas и sobre las fuentes y el método.
Resumen
Nostr no es una plataforma, sino un protocolo. El nombre significa Notes and Other Stuff Transmitted by Relays — «notas y otras cosas transmitidas por relés». El sitio nostr.com lo describe así: «una red libre y abierta que nadie posee y que nadie controla».
La estructura es sencilla y sobre ella se sostiene todo lo demás. Hay relés: servidores que almacenan y distribuyen los mensajes. Hay clientes: aplicaciones a través de las cuales la gente lee y escribe. Y hay claves: la clave pública funciona como nombre de usuario y la privada como contraseña; son las claves, y no una empresa, las que te dan derecho a tu identidad. Como la identidad pertenece a la clave y no a la aplicación, puedes pasar de un cliente a otro conservando el perfil, los suscriptores y las publicaciones.
Técnicamente todo se reduce a un solo tipo de objeto. El documento base del protocolo dice: el único tipo de objeto que existe es el «evento» (event), las firmas y las claves usan el esquema de Schnorr sobre la curva secp256k1, y el relé expone hacia fuera un punto websocket al que el cliente envía tres tipos de mensaje: EVENT para publicar, REQ para suscribirse a una selección y CLOSE para cerrarla.
Para este directorio eso significa lo siguiente: Nostr no tiene dueño, ni una audiencia única, ni panel publicitario, ni reglas de moderación, ni programa de pagos. A continuación se analiza qué hay en su lugar.
Quién está aquí
La cifra de audiencia de Nostr no existe, y no puede existir en el sentido habitual. No hay un servidor central que cuente a los usuarios: hay multitud de relés independientes, y cada uno ve solo a los suyos.
De forma indirecta solo cabe juzgar por relés concretos. El cliente de nostr.com se conecta por defecto a seis relés y muestra su lista directamente en la interfaz: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom y relay.snort.social. El proyecto recomienda consultar el catálogo de relés en la herramienta externa Nostr.watch, y el catálogo de clientes en nostrapps.com (página sobre los relés, página sobre los clientes).
No hay desglose por idioma ni por país, y no puede haberlo: el protocolo no guarda esa información sobre el usuario. Por defecto el perfil contiene solo nombre, descripción e imagen.
Cómo empezar
No hay registro en el sentido habitual: la cuenta es un par de claves que genera la aplicación. Ni confirmación de correo, ni número de teléfono, ni moderación de la solicitud.
De ahí se deriva el riesgo principal, del que advierte el propio proyecto: la clave privada da acceso completo a la cuenta — con ella se puede publicar en tu nombre, cambiar el perfil y enviar mensajes; si la clave se pierde y no hay copia, no existe el botón de «¿olvidaste tu contraseña?». Consejo práctico del proyecto: no metas la clave privada en cualquier aplicación — es más seguro usar una extensión de navegador para firmar o un firmante remoto.
Sí es posible conseguir un nombre verificable, parecido a una «marca de verificación»: un documento aparte del protocolo describe la vinculación de la clave a un dominio. El cliente toma del perfil una dirección del tipo nombre@dominio, solicita https://dominio/.well-known/nostr.json?name=nombre y compara la clave pública obtenida con la clave del autor de la publicación. Para una empresa ese es justamente el modo de confirmar que la cuenta es realmente suya: la confirmación la da el control del dominio, no la decisión de un moderador.
No hay una cuenta comercial aparte, como tampoco la hay corriente. La presencia de una empresa en Nostr es una clave vinculada a su dominio y, si lo desea, un relé propio.
Qué se puede publicar
Los formatos vienen dados por los «tipos» de eventos, y los tipos se describen en documentos aparte: los NIP (Nostr Implementation Possibilities). Su listado se mantiene en un repositorio abierto e incluye, entre otras cosas: notas breves e hilos de discusión, materiales largos, imágenes y vídeos, emisiones en directo y «spaces», encuestas, eventos de calendario, wikis, torrents, listas, marcadores y citas (listado de NIP).
El protocolo no impone límites de longitud ni de tamaño: los impone el relé, y el relé está obligado a declararlos. El documento sobre la información del relé describe los campos: max_message_length — tamaño máximo del JSON entrante en bytes (que de hecho limita también el tamaño del evento), max_content_length — número máximo de caracteres en el campo de contenido, max_event_tags — número máximo de etiquetas, max_subscriptions — número de suscripciones simultáneas en una misma conexión, max_limit — tope del número de eventos en la respuesta a una sola consulta.
Así se ve en la práctica. El relé relay.damus.io declara en la fecha de verificación un límite de mensaje de 1 000 000 de bytes, 200 suscripciones y un tope de selección de 500 eventos; el relé nos.lol — 131 072 bytes, 20 suscripciones, los mismos 500 eventos; el relé relay.nostr.com — 131 072 bytes, 200 suscripciones, 500 eventos. Las cifras pertenecen a cada relé por separado, y en otro relé serán distintas.
El protocolo no tiene prohibiciones de contenido. Sí hay marcado técnico: un documento aparte describe el etiquetado de contenido sensible, otro las denuncias sobre eventos, y un tercero la solicitud de borrado. Fíjate en la palabra «solicitud»: el borrado en Nostr es una petición a los relés, no una garantía. Qué aceptar y qué conservar lo decide el dueño del relé.
Cómo crecer
En el protocolo no hay feed algorítmico. Qué mostrar al usuario lo decide el cliente, y qué eventos entregar, el relé. El cliente de nostr.com lo muestra de forma explícita: en su interfaz hay opciones de feed «suscripciones», «global» y «propio», y más abajo una lista de los relés conectados.
De ahí se deriva una consecuencia práctica que el propio proyecto explica: si Nostr parece lento o vacío, la causa pueden ser los relés; una parte de los relés son rápidos y fiables, otra se desconecta y no responde, y añadir unos cuantos relés buenos cambia mucho las cosas. Crecer en Nostr consiste, ante todo, en publicar en aquellos relés donde realmente hay lectores.
No existe panel publicitario: el protocolo no tiene ni una plataforma que venda impresiones ni un mecanismo para contabilizarlas. Tampoco hay estadísticas integradas; lo más parecido es la consulta COUNT, que el relé ejecuta en la medida de lo posible y de forma aproximada.
El protocolo propone un medio poco habitual contra el spam: el documento sobre la prueba de trabajo permite al relé exigir a los eventos nuevos una complejidad de cálculo determinada. El segundo medio es el dinero: una parte de los relés son de pago, y eso reduce el spam, porque mantener un relé cuesta dinero y los usuarios tienen un motivo para comportarse con corrección.
Camino hacia la monetización
No hay plataforma, así que tampoco hay pagos de la plataforma. En cambio, sí hay pagos directos entre personas, y están descritos en el propio protocolo.
El mecanismo se llama «zap»: un pago a través de la red Lightning. El documento del protocolo introduce dos tipos de eventos: 9734 — la solicitud de zap, es decir, la petición del pagador a la cartera del destinatario para que emita una factura, y 9735 — el recibo, la confirmación de la cartera del destinatario de que la factura está pagada. El curso es este: el cliente toma del perfil del destinatario la dirección de su punto de pago, comprueba que admite Nostr, envía allí una solicitud firmada y recibe una factura; tras el pago, la cartera publica el recibo. El sentido del recibo se explica en el mismo sitio: permite a los clientes mostrar los pagos directamente en el feed — por gusto o como medio de lucha contra el spam.
En este esquema no hay comisión de la plataforma: el dinero va de cartera a cartera. Pero tampoco hay garantías de la plataforma: de la entrega del pago responden la red Lightning y el proveedor de cartera que elijas.
Además de los zaps, el listado del protocolo contiene otros mecanismos monetarios: objetivos de recaudación (zap goals), insignias, carteras Cashu y «nutzaps», conexión remota de cartera y eventos de pedidos entre personas. Cada uno de ellos lo implementa el cliente si así lo desea.
Herramientas y automatización
Nostr no tiene «API oficial» por la misma razón por la que no tiene dueño: el propio protocolo es la interfaz. Cualquier programa puede abrir un websocket hacia un relé y trabajar con él directamente (documento base). No existen claves de desarrollador, ni solicitudes de acceso, ni moderación de aplicaciones.
Antes de construir una herramienta conviene leer la advertencia del propio listado: «Los NIP de aquí no son una lista de comprobación del protocolo. Nada obliga a ningún programa a implementar ningún NIP. Cada aplicación elige el subconjunto que necesita para su tarea». Eso significa que no se puede contar con una función solo porque esté descrita: hay que comprobar si un relé concreto la admite. Está previsto el modo de comprobarlo: el relé entrega por HTTP un documento con la lista de los NIP que admite, el nombre del programa, la versión, los contactos y un enlace a sus condiciones de servicio. Los tres relés mencionados arriba declaran el mismo conjunto: los tres funcionan con el programa strfry y admiten los NIP 1, 2, 4, 9, 11, 28, 40, 45, 70 y 77.
Entre los medios ya disponibles, el proyecto menciona las extensiones de navegador para firmar y los firmantes remotos, así como su propio firmante, Pomegranate. Los catálogos de clientes y de relés se mantienen fuera del protocolo: en nostrapps.com y Nostr.watch (página sobre los clientes, página sobre los relés).
Límites y reglas
- No hay reglas comunes. No existe ni un solo documento que prohíba algo a todos los participantes de la red. Las reglas las fija el dueño del relé; el protocolo solo prevé un enlace a las condiciones de servicio en la información del relé.
- Los límites los fija el relé y él mismo los declara: tamaño del mensaje, longitud del contenido, número de etiquetas, número de suscripciones, tope de la selección.
- El relé puede exigir entrada mediante el protocolo de autenticación o prueba de trabajo para los eventos nuevos.
- El borrado no está garantizado: el documento describe precisamente una «solicitud de borrado», y cada relé decide si ejecutarla o no.
- La pérdida de la clave es irreversible. No hay recuperación del acceso.
- La red no tiene marco jurídico. La responsabilidad recae en el dueño del relé y en el autor; el protocolo no tiene una persona jurídica con la que firmar un contrato. El propio listado de NIP se publica en un repositorio sin licencia indicada.
Para quién es
Es adecuado para proyectos a los que les importa la independencia respecto al dueño de la plataforma: la identidad pertenece a la clave, y no a una empresa, la cuenta no puede bloquearse de forma centralizada, y si un relé no convence basta con cambiar de relé. Es adecuado para desarrolladores: conectarse a la red no requiere ni clave de aplicación ni aprobación.
Es adecuado para proyectos ligados a bitcoin y Lightning: los pagos están integrados en el protocolo en forma de zaps, y esa es la parte más desarrollada de su mecánica monetaria.
No es adecuado si necesitas alcance previsible e informes: aquí no hay nada que medir — ni plataforma, ni estadísticas, ni panel publicitario. No es adecuado para el envío masivo ni para la «promoción»: el relé tiene derecho a exigir un pago, una autenticación o una prueba de trabajo y a desconectarte sin explicaciones. Y no es adecuado si en la organización se exige un contrato con un proveedor de servicios: el protocolo no tiene esa parte.
Datos verificados de la base
Los datos comprobados en los que se apoya el análisis.
Qué es esta plataforma
la plataforma se describe así: «Nostr is a free and open-source protocol for social media and other things - controlled by users, not platforms.»
autodescripción: es una declaración de la plataforma sobre sí misma, no una evaluación independiente
fuente, comprobado 2026-07-28
Nostr (Notes and Other Stuff Transmitted by Relays) se describe como una red libre y abierta que nadie posee ni controla; los relés almacenan y reparten los mensajes, los clientes permiten leerlos y escribirlos
Es un protocolo, no una plataforma: no tiene dueño, ni panel publicitario, ni programa de pagos
fuente, comprobado 2026-07-28
el único tipo de objeto es el evento (event); las firmas y las claves usan el esquema de Schnorr sobre la curva secp256k1; el relé expone un punto websocket y el cliente envía EVENT para publicar, REQ para suscribirse y CLOSE para cerrar la suscripción
Documento base del protocolo, el NIP-01
fuente, comprobado 2026-07-28
Por dónde empezar
el umbral de entrada de nostr no tiene un dueño único de las reglas: «Nostr (Notes and Other Stuff Transmitted by Relays) is a free and open network that nobody owns or controls»; el compendio de propuestas del protocolo estipula lo mismo sobre sí: «NIPs listed here are not a protocol checklist. Nothing forces any software to implement any NIP»
citas literales, el idioma de la fuente es el inglés. La segunda procede del README del compendio de NIP: https://raw.githubusercontent.com/nostr-protocol/nips/master/README.md. Conclusión práctica para el lector: no existen condiciones de entrada únicas obligatorias para toda la red; las condiciones las pone cada relé y cada aplicación por separado, y son distintas
fuente, comprobado 2026-08-07
un relé puede cerrar la escritura, exigir entrada con firma o prueba de trabajo: en la lista de restricciones del NIP-11 figuran «auth_required», «restricted_writes», «min_pow_difficulty», «payment_required»; «Your client should expect that requests exceed these practical limitations are rejected or fail immediately»
citas literales, el idioma de la fuente es el inglés, se conserva la ortografía de la fuente. A nivel del protocolo no hay solicitudes, invitaciones ni moderación; todo lo enumerado son propiedades de un relé concreto, y se conocen pidiendo al relé su documento de información
fuente, comprobado 2026-08-07
Cuenta y acceso
la cuenta es un par de claves, no un registro en manos del dueño de la plataforma: «Every account has Nostr keys. Your public key is like your username and can be shared with anyone. Your private key is like your password and must be kept safe. These keys give you ownership of your identity, rather than a company owning it for you»
cita literal, el idioma de la fuente es el inglés. Para obtener las claves no se exige registro, ni verificación de identidad, ni aprobación: el par de claves se genera en el dispositivo. El nombre verificable opcional del tipo nombre@dominio se describe en un NIP aparte, el NIP-05
fuente, comprobado 2026-08-07
la cuenta tiene un par de claves: la pública funciona como nombre de usuario y la privada como contraseña; la identidad pertenece a la clave y no a la aplicación, así que puedes cambiar de cliente conservando el perfil y los seguidores
No hay registro, ni confirmación de correo, ni moderación de solicitudes
fuente, comprobado 2026-07-28
si pierdes la clave privada sin copia de seguridad, el acceso no se recupera: el botón de «olvidé la contraseña» no existe
El proyecto aconseja no pegar la clave privada en cada aplicación, sino usar una extensión firmante o un firmante remoto
fuente, comprobado 2026-07-28
nombre verificable del tipo nombre@dominio: el cliente consulta https://dominio/.well-known/nostr.json?name=nombre y compara la clave pública recibida con la clave del autor de la publicación
Para una empresa es una forma de confirmar la cuenta mediante el control del dominio, no por decisión de un moderador
fuente, comprobado 2026-07-28
Qué se puede publicar
el compendio de NIP describe, entre otras cosas: notas cortas e hilos, materiales largos, imágenes y vídeo, emisiones en directo y espacios, encuestas, eventos de calendario, wikis, torrents, listas, marcadores y citas
La lista de NIP no es un conjunto de obligaciones: nada obliga a un programa a implementar NIP alguno
fuente, comprobado 2026-07-28
Cómo se paga aquí
A quién se admite. los pagos no tienen umbral de seguidores, de visualizaciones ni de número de publicaciones: los zaps van directamente de persona a persona por la red Lightning, y la única condición es que el receptor tenga un monedero con dirección lnurl — «Client calculates a recipient's lnurl pay request url from the zap tag on the event being zapped, or by decoding their lud16 field on their profile»
cita literal, el idioma de la fuente es el inglés. Umbral cero: el NIP-57 no exige número de seguidores, ni horas de visualización, ni antigüedad de la cuenta. Los importes límite los fija el monedero del receptor con los campos «minSendable» y «maxSendable», no la red
fuente, comprobado 2026-08-07
la red no tiene comisión ni hay nadie que pudiera cobrarla: el dinero pasa al margen del protocolo, a través del monedero del receptor, y nostr no participa en la liquidación — el NIP-57 describe solo dos tipos de eventos, el registro de la solicitud y el registro del recibo: «9734 is a zap request… 9735 is a zap receipt, representing the confirmation by the recipient's lightning wallet that the invoice issued in response to a zap request has been paid»
cita literal, el idioma de la fuente es el inglés. Su propia comisión la puede cobrar el monedero o un nodo de la red Lightning — eso ya no es nostr, y su importe no está fijado en el NIP-57. La red no tiene comisión, ni participación, ni umbral de pago, porque no hay intermediario que retenga el dinero
fuente, comprobado 2026-08-07
los pagos entre personas se describen en el protocolo como «zaps» a través de la red Lightning: el evento 9734 es la solicitud de zap y el evento 9735, el recibo del monedero del receptor sobre el pago de la factura
En el esquema no hay comisión de la plataforma: el dinero va de monedero a monedero; la responsabilidad de la entrega recae en la red Lightning y en el proveedor del monedero
fuente, comprobado 2026-07-28
el compendio de NIP contiene además metas de recaudación (zap goals), insignias, monederos Cashu y nutzaps, conexión remota del monedero y eventos de pedidos entre personas
Cada mecanismo lo implementa el cliente si quiere
fuente, comprobado 2026-07-28
Cuánto cuesta
el protocolo no cobra dinero, pero un relé concreto puede hacerlo: el NIP-11 prevé campos para tarifas — «Relays that require payments may want to expose their fee schedules»: «fees»: «admission» (tarifa de admisión), «subscription» (suscripción con el campo «period»), «publication» (tarifa por publicación, con indicación de los tipos de eventos); en la lista de restricciones del relé figura el indicador «payment_required»
citas literales, el idioma de la fuente es el inglés. Los números los fija cada relé por sí mismo, así que la red no tiene un precio de entrada único. El ejemplo incluido en el propio NIP-11 como muestra de respuesta del relé nostr.wine: «fees»: «admission»: ({«amount»: 18888000, «unit»: «msats»}) — es la declaración del relé en el ejemplo del documento, no un cálculo nuestro ni una promesa del precio actual
fuente, comprobado 2026-08-07
Límites y restricciones
el relé declara sus restricciones en el documento de información: max_message_length (tamaño del JSON entrante), max_content_length (caracteres del campo de contenido), max_event_tags, max_subscriptions, max_limit; son posibles requisitos de autenticación y de prueba de trabajo
Documento NIP-11; el protocolo no tiene restricciones propias de longitud ni de tamaño
fuente, comprobado 2026-07-28
el relé relay.damus.io, en la fecha de la comprobación, declara un límite de mensaje de 1 000 000 de bytes, 200 suscripciones simultáneas y un tope de consulta de 500 eventos; software strfry
El número pertenece a este relé; en otro es distinto
fuente, comprobado 2026-07-28
el relé nos.lol declara un límite de mensaje de 131 072 bytes, 20 suscripciones y un tope de consulta de 500 eventos
Medido solicitando el documento de información del relé
fuente, comprobado 2026-07-28
el relé relay.nostr.com declara un límite de mensaje de 131 072 bytes, 200 suscripciones y un tope de consulta de 500 eventos; los NIP declarados: 1, 2, 4, 9, 11, 28, 40, 45, 70, 77
El mismo conjunto de NIP lo declaran damus.io y nos.lol
fuente, comprobado 2026-07-28
Restricciones
no hay reglas únicas: qué aceptar y almacenar lo decide el dueño del relé; el protocolo solo prevé un enlace a las condiciones de servicio en la información del relé
El borrado se describe como una «solicitud de borrado» y su ejecución no está garantizada
fuente, comprobado 2026-07-28
medios contra el spam: el relé puede exigir una prueba de trabajo de dificultad dada o autenticación; parte de los relés son de pago, lo que, según explica el proyecto, reduce el spam
Nostr.watch está recomendado por el proyecto como catálogo de relés y nostrapps.com, como catálogo de clientes
fuente, comprobado 2026-07-28
el archivo para robots de nostr.com permite a todos los agentes rastrear el sitio
Comprobado por separado
fuente, comprobado 2026-07-28
Aspectos legales
el repositorio de la lista de NIP está publicado sin licencia indicada
El protocolo no tiene persona jurídica con la que se pueda firmar un contrato
fuente, comprobado 2026-07-28
Acceso por API
el cliente de nostr.com se conecta por defecto a seis relés: relay.nostr.com, relay.damus.io, nos.lol, nostr.bitcoiner.social, nostr.mom, relay.snort.social
La lista se ve directamente en la interfaz
fuente, comprobado 2026-07-28
no existe una «API oficial» aparte: la interfaz es el propio protocolo y cualquier programa puede abrir un websocket hacia un relé; no existen claves de desarrollador ni moderación de aplicaciones
La compatibilidad con capacidades concretas hay que comprobarla en el documento de información del relé
fuente, comprobado 2026-07-28
Idiomas
idioma de la interfaz de la página principal: en
El idioma se tomó del atributo del marcado; las versiones, de los hreflang
fuente, comprobado 2026-07-28
Sección del catálogo: todos los similares Véase también: índice del catálogo · comparativa de planificadores · selección por situación · restricciones de las plataformas