Cuando un relay dice no: los rechazos especificados en NIP-01

La página es la segunda sección de la columna sobre relays en la demo educativa de Nostr. Se explica que publicar puede fallar, y que NIP-01 define con precisión cómo: el relay responde con OK falso y un mensaje que empieza con un prefijo legible por máquina. Así, un cliente puede distinguir un reintento posible de un rechazo definitivo.

Funcionalidades principales

• Rechazos provocables: el visitante puede disparar cada tipo de rechazo a propósito, algo que ningún relay público permitiría, y observar tanto el evento como la respuesta del relay.
• Cinco motivos de rechazo: autenticación requerida, límite de velocidad, política de contenido, límite de tamaño y prueba de trabajo exigida.
• Restablecimiento del relay: controles para volver a aceptar todo y limpiar el estado del relay local entre experimentos.
• Lectura del prefijo: la demo enfatiza que la parte útil de la respuesta es el prefijo inicial, que indica al cliente qué hacer a continuación.

Idea central

Cada rechazo dice por qué ocurre. Un cliente que lee el prefijo puede actuar con sensatez en lugar de mostrar una cadena de error.

El rechazo no es un fallo del sistema sino parte del diseño: relays simples con políticas claras y comunicadas de forma estandarizada.

Las cinco formas de rechazo

1. auth-required: el relay solo acepta eventos de miembros. Un cliente real responde con un intercambio NIP-42 demostrando que controla la clave y reintenta.
2. rate-limited: el evento llegó demasiado rápido y no se almacenó. Un cliente bien comportado reduce la velocidad en lugar de insistir.
3. restricted: el relay rechaza ese tipo de evento. Un relay de artículos largos podría aceptar solo el kind 30023. Es política, no protocolo.
4. invalid: el evento no pasa las reglas del relay, como un límite de tamaño. En la demo el límite es de treinta y dos caracteres.
5. pow: el relay exige prueba de trabajo según NIP-13: un identificador de evento que empiece por cierto número de ceros, lo que cuesta cómputo real. Es caro para un spammer y apenas perceptible para una nota.

Qué significa cada prefijo para el cliente

• rate-limited: esperar y reintentar más tarde.
• auth-required: autenticar y reintentar.
• restricted: y blocked: publicar en otro lugar.

Por qué se publica en varios relays

Cualquiera de los relays puede rechazar un evento por razones no relacionadas con el evento mismo: política de contenido, límites de tamaño o requisitos de membresía. El que lo acepte es tan bueno como cualquier otro, y la redundancia garantiza que el evento circule aunque algunos relays digan que no.

La lección muestra que el rechazo en Nostr está especificado, no improvisado. Al definir prefijos de error legibles por máquina, el protocolo permite que los clientes distingan un retraso temporal de un rechazo definitivo y actúen en consecuencia. Los relays rechazan cosas de unas pocas formas concretas, y cada una de ellas dice por qué.

• Aqui esta el link de la fuente: https://rookery-six.vercel.app/