← Todos los NIPs

NIP-66

Descubrimiento de relays y monitoreo de disponibilidad

BorradorEventosRelay

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.

De un vistazo

Estado
En uso, pero todavía puede cambiar.
Kinds
Tags
  • c
  • d
  • frequency
  • g
  • l
  • n
  • N
  • R
  • rtt-open
  • t
  • timeout
Último cambio
28 may 2026

Pruébalo

Edita el formulario o el JSON: ambos se mantienen sincronizados, la insignia indica si el resultado es válido y, al tocar cualquier campo, se explica qué hace.

Qué construir

Cómo se conectan las partes: Monitorear relays

Ejemplos
Válido 1 nota

Aún sin firmar · Solo claves de demo. Las claves secretas de estos personajes son públicas a propósito.

Formulario
1 ene 2025, 0:00 UTC

Contenido

Opcional: el documento NIP-11 del relay como string JSON. Puede ir vacío.

Tags

  1. d Obligatorio

    El relay del que trata este informe.

  2. n Opcional

    Red en la que está el relay.

  3. T Opcional

    Tipo de relay en PascalCase, p. ej. PrivateInbox o PublicOutbox.

  4. N Opcional

    Un NIP que soporta el relay. Un tag por NIP.

  5. N Opcional

    Un NIP que soporta el relay. Un tag por NIP.

  6. N Opcional

    Un NIP que soporta el relay. Un tag por NIP.

  7. N Opcional

    Un NIP que soporta el relay. Un tag por NIP.

  8. R Opcional

    Un requisito de las limitaciones NIP-11: auth, writes, pow, payment.

  9. R Opcional

    Un requisito de las limitaciones NIP-11: auth, writes, pow, payment.

  10. R Opcional

    Un requisito de las limitaciones NIP-11: auth, writes, pow, payment.

  11. k Opcional

    Un kind que el relay acepta, o rechaza con el prefijo !.

  12. g Opcional

    Dónde está el relay, como geohash.

  13. l Opcional

    Una etiqueta, p. ej. el idioma principal del relay.

  14. rtt-open Opcional

    Cuánto tardó en abrirse una conexión.

  15. rtt-read Opcional

    Cuánto tardó una lectura (de REQ a la primera respuesta).

  16. rtt-write Opcional

    Cuánto tardó una escritura (de EVENT a OK).

Añadir tag

Cómo funciona este NIP

Paso 1 de 5

Un monitor se anuncia

Un evento de kind 10166 dice que esta clave publica informes de relays con regularidad: con qué frecuencia, qué comprobaciones hace y sus tiempos de espera.

En el curso

Se basa en

Ver también

Especificación

El texto de las especificaciones se cita en inglés del repositorio nostr-protocol/nips. Nuestras explicaciones y la interfaz están traducidas. Código fuente en GitHub en el commit 0046368

Leer la especificación598 palabras, citadas del repositorio en el commit 0046368.

This NIP defines events for relay discovery and the announcement of relay monitors.

Relay Discovery Events

30166 relay discovery events document relay characteristics inferred either from a relay's NIP 11 document, or via probing.

Information corresponding to field in a relay's NIP 11 document MAY contradict actual values if monitors find that a different policy is implemented than is advertised.

content MAY include the stringified JSON of the relay's NIP-11 informational document.

The only required tag is the d tag, which MUST be set to the relay's normalized URL. For relays not accessible via URL, a hex-encoded pubkey MAY be used instead.

Other tags include:

  • rtt-open - The relay's open round-trip time in milliseconds.
  • rtt-read - The relay's read round-trip time in milliseconds.
  • rtt-write - The relay's write round-trip time in milliseconds.
  • n - The relay's network type. SHOULD be one of clearnet, tor, i2p, loki
  • T - The relay type. Enumerated relay type formatted as PascalCase, e.g. PrivateInbox
  • N - NIPs supported by the relay
  • R - Keys corresponding to requirements per NIP 11's limitations array, including auth, writes, pow, and payment. False values should be specified using a ! prefix, for example !auth.
  • t - A topic associated with this relay
  • k - Accepted and unaccepted kinds (false values prepended by !)
  • g - A NIP-52 geohash

Tags with more than one value should be repeated, rather than putting all values in a single tag, for example [["t", "cats"], ["t", "dogs"]], rather than [["t", "cats", "dogs"]].

Example:

{
  "id": "<eventid>",
  "pubkey": "<monitor's pubkey>",
  "created_at": "<created_at  [some recent date ...]>",
  "signature": "<signature>",
  "content": "<optional nip 11 document>",
  "kind": 30166,
  "tags": [
    ["d","wss://some.relay/"],
    ["n", "clearnet"],
    ["N", "40"],
    ["N", "33"],
    ["R", "!payment"],
    ["R", "auth"],
    ["g", "ww8p1r4t8"],
    ["l", "en", "ISO-639-1"],
    ["t", "nsfw" ],
    ["rtt-open", "234" ]
  ]
}

Relay Monitor Announcements

Kind 10166 relay monitor announcements advertise the author's intent to publish 30166 events. This event is optional and is intended for monitors who intend to provide monitoring services at a regular and predictable frequency.

Tags include:

  • frequency - The frequency in seconds at which the monitor publishes events.
  • timeout (optional) - The timeout values for various checks conducted by a monitor. Index 1 is the monitor's timeout in milliseconds. Index 2 describes what test the timeout is used for. If no index 2 is provided, it is inferred that the timeout provided applies to all tests.
  • c - a lowercase string describing the checks conducted by a monitor. Examples include open, read, write, auth, nip11, dns, and geo.
  • g - NIP-52 geohash tag

Monitors SHOULD also publish a kind 0 profile and a kind 10002 relay selections event.

Example:

{
  "id": "<eventid>",
  "pubkey": "<monitor's pubkey>",
  "created_at": "<created_at  [some recent date ...]>",
  "signature": "<signature>",
  "content": "",
  "tags": [
    [ "timeout", "open", "5000"  ],
    [ "timeout", "read", "3000"  ],
    [ "timeout", "write", "3000" ],
    [ "timeout", "nip11", "3000" ],
    [ "frequency", "3600" ],
    [ "c", "ws" ],
    [ "c", "nip11" ],
    [ "c", "ssl" ],
    [ "c", "dns" ],
    [ "c", "geo" ]
    [ "g", "ww8p1r4t8" ]
  ]
}

Risk Mitigation

  • Clients MUST NOT require 30166 events to function. Absence of monitoring data MUST NOT prevent relay connections.
  • A monitor may publish erroneous 30166 events, either by misconfiguration or malicious intent.
  • Clients SHOULD NOT trust a single source. Defenses include: web-of-trust filtering, querying multiple monitors, and discarding filter results if they would remove an unreasonable proportion of relays.