Nostr WoT
NostrNostr WoTNIP-98Seguridad

Nostr WoT 0.8.10 aísla las aprobaciones de inicio no estándar

La versión 0.8.10 permite continuar un inicio heredado admitido sin convertirlo en un permiso reutilizable. Cada solicitud queda separada.

Nostr WoT Newsroom

Artículo4 min de lectura

Elaborado por la Redacción de Nostr WoT a partir de las fuentes primarias citadas, y publicado automáticamente sin revisión humana individual.

Nostr WoT 0.8.10 aísla las aprobaciones de inicio no estándar

Nostr WoT extension 0.8.10 mantiene el inicio de sesión web para un cliente expresamente admitido que envía un evento de autenticación no estándar. La compatibilidad está limitada: la extensión identifica la solicitud como un acceso heredado, muestra una advertencia de riesgo y exige una aprobación nueva y de un solo uso cada vez.

La versión se publicó el 1 de octubre con archivos descargables para Chrome y Firefox, código fuente correspondiente y sumas de comprobación. Esos archivos demuestran que 0.8.10 está disponible en GitHub. No demuestran que las tiendas de ambos navegadores hayan aprobado o distribuido la misma versión.

El formato heredado no se trata como NIP-98

La solicitud admitida usa el tipo 22242 con etiquetas domain y challenge. No es autenticación de relé NIP-42 ni cumple NIP-98.

NIP-98 usa el tipo 27235. Su etiqueta obligatoria u contiene la URL absoluta, incluidos los parámetros de consulta, y method indica el método HTTP. El servidor también comprueba una marca temporal reciente, y las solicitudes con cuerpo pueden incluir un hash payload. Estos datos vinculan la firma a una acción HTTP más concreta que un dominio por sí solo.

La versión 0.8.10 no presenta el evento heredado como estándar. La pantalla advierte que su vínculo con el dominio es más débil porque la firma no identifica una URL exacta del backend ni un método HTTP. También pide contactar con los desarrolladores del sitio para que adopten NIP-98.

Cada solicitud sigue siendo una decisión separada

La comparación con 0.8.9 muestra el límite en el código. Una solicitud heredada no puede heredar una concesión guardada. La búsqueda de permisos no devuelve una decisión reutilizable para este protocolo, por lo que la cola debe volver a preguntar.

La interfaz ofrece solo dos resultados: aprobar esta solicitud una vez o rechazarla. Elimina la aprobación persistente del sitio y la aprobación para sitios conectados en esta ruta. Dos solicitudes del mismo origen se conservan como dos revisiones, no como una acción agrupada.

La automatización del backend y las concesiones guardadas para relés no pueden autorizar el formato heredado. También se mantienen las comprobaciones del frame, el origen verificado, la cuenta activa y la marca temporal. Se rechazan clientes desconocidos, dominios incorrectos, etiquetas duplicadas, desafíos vacíos y eventos con datos de URL o método en el formato equivocado.

Esta separación evita que la compatibilidad se convierta en política por accidente. Una persona puede completar un inicio concreto sin conceder al sitio una capacidad indefinida para pedir más firmas heredadas.

La versión también añade comentarios opcionales al desinstalar

El segundo cambio visible registra https://nostrwot.com/uninstall mediante la API de desinstalación del navegador. Los navegadores compatibles pueden abrir esa página después de eliminar la extensión. La URL no contiene identificadores de cuenta, datos de cartera ni parámetros de seguimiento.

Abrir la página sigue creando una solicitud web normal al sitio y enviar comentarios es opcional. Solo el formulario enviado transmite el texto y el correo opcional escritos por la persona. Los navegadores sin esa API omiten el registro y un fallo de la API no detiene el worker.

Lo que la versión no demuestra

La versión aporta paquetes, código y sumas de comprobación, y el diff añade pruebas para la revisión repetida, las restricciones de origen y la URL de desinstalación. No convierte el tipo 22242 en un estándar ni le da el vínculo por solicitud de NIP-98.

El resultado es una excepción contenida, no una recomendación. Los usuarios pueden reconocer la advertencia y decidir sobre una solicitud. Los desarrolladores siguen necesitando NIP-98 cuando el inicio web debe vincular una firma a un destino HTTP y a un método exactos.

Fuentes

Toda afirmación de este artículo enlaza a una fuente primaria.

  1. Versión 0.8.10 de la extensión Nostr WoT — nostr-wot/nostr-wot-extension (1 de octubre de 2026)
  2. Cambios de v0.8.9 a v0.8.10 — nostr-wot/nostr-wot-extension (1 de octubre de 2026)
  3. NIP-98: HTTP Auth en el commit 0046368 — nostr-protocol/nips (27 de septiembre de 2026)

Mantente al día

Recibe noticias sobre las versiones publicadas de Nostr WoT, nuevas funciones e integraciones.

Recibirás el boletín en español.

Guardamos tu dirección de correo electrónico y tu idioma preferido para enviarte el boletín.

Boletines