NIP-67: indicio de integridad de EOSE

El vacío que dejaba EOSE

La mayoría de los relays aplican un límite interno a la cantidad de eventos almacenados que devuelven para una sola suscripción, independiente del limit que haya pedido el cliente. El cliente no tiene forma de ver ese límite. Lo único que puede hacer es comparar el número de eventos que recibió contra el limit que solicitó, y adivinar.

Esa suposición falla de dos formas concretas.

Primero, cuando el límite del relay está por debajo del limit solicitado por el cliente, el cliente cree erróneamente que el resultado está completo. Un cliente pide las últimas 500 notas. El relay limita las respuestas a 300 y envía exactamente 300. Como 300 es menor que 500, el cliente concluye que tiene todo. No es así. El resto de las notas que coinciden siguen en el relay, y el cliente nunca se entera de que existen.

Segundo, cuando el número de eventos coincidentes resulta ser exactamente igual al límite del relay, el cliente no puede saber que los recibió todos. No le queda otra opción que enviar otro REQ con until fijado en la marca de tiempo del evento más antiguo recibido, solo para confirmar que el siguiente lote está vacío. Un relay limitado a 300 eventos recibe al menos dos consultas para cualquier suscripción que alcance ese límite, haya o no más datos por obtener.

Qué añade NIP-67

La especificación añade un tercer elemento opcional al mensaje EOSE, un arreglo de cadenas de indicio:

["EOSE", <subscription_id>, [<hint>, ...]]

Se definen dos valores de indicio. "finish" significa que el relay envió todos los eventos almacenados que coinciden con los filtros de la suscripción, así que el cliente no debería paginar más. "more" significa que el relay está reteniendo eventos coincidentes adicionales que no ha enviado, así que el cliente debería paginar para obtenerlos. Un relay no está obligado a enviar "more" incluso cuando sea cierto, ya que saber con certeza que existen más datos coincidentes no es gratis en todos los backends de almacenamiento.

El arreglo de indicios puede llevar uno de los valores, ambos, o ninguno. La especificación es explícita: su presencia es definitiva y su ausencia no lo es. Si un relay omite el tercer elemento por completo, o envía un EOSE sin indicios, el cliente recae en la misma heurística de paginación basada en until que ya usa hoy. Nada del comportamiento actual del cliente tiene que cambiar para seguir siendo correcto.

La compatibilidad funciona en ambas direcciones. Un relay que agrega este NIP envía el EOSE de tres elementos a todos los clientes, entiendan o no el indicio, porque los clientes que no implementan NIP-67 ya indexan EOSE por posición y simplemente ignoran el elemento adicional, tal como un parser de JSON acepta sin problema un elemento extra al final de un arreglo. Un cliente que agrega soporte para el indicio no obtiene nada extra de los relays que aún no lo implementan, y simplemente sigue usando su lógica de paginación actual.

El NIP también aborda un caso límite relacionado con marcas de tiempo empatadas. Cuando un relay no envía "finish", varios eventos almacenados pueden compartir el mismo valor de created_at más antiguo en una respuesta, y la paginación basada en until corre el riesgo de descartar silenciosamente eventos que comparten esa marca de tiempo límite. Se recomienda a los relays, cuando sea posible, avanzar lo suficiente para que todos los eventos con esa marca de tiempo límite queden incluidos en una sola respuesta, y emitir "finish" solo cuando realmente no quede nada más antiguo.

Se espera que los relays que implementen NIP-67 incluyan 67 en su campo supported_nips, según el NIP-11.

Por qué importa

Un truncamiento silencioso y un resultado genuinamente vacío se ven idénticos para un cliente hoy en día. Esa distinción importa sobre todo para cualquier cosa que trate "no hay más resultados" como algo significativo: consultas de moderación, auditorías, o un cliente que intenta establecer que una clave pública determinada realmente no tiene más eventos de cierto tipo. NIP-67 no cambia cómo se almacenan o entregan los eventos. Le da a los relays un pequeño vocabulario opcional para decir la verdad sobre si el historial de eventos almacenados de una suscripción realmente se agotó.