Nostr WoT 0.8.10 isolates nonstandard login approvals

The legacy format is not treated as NIP-98

The supported legacy request uses kind 22242 with domain and challenge tags for website login. It is not NIP-42 relay authentication, and it does not follow NIP-98.

NIP-98 uses kind 27235. Its required u tag names the absolute request URL, including query parameters, while method names the HTTP method. Servers also check a recent timestamp, and requests with a body may include a payload hash. Those fields bind the signature to a more specific HTTP action than a domain name alone.

Version 0.8.10 does not relabel the legacy event as standards-compliant. The approval screen warns that its domain-level binding is weaker because the signature does not identify an exact backend URL or HTTP method. It also asks users to contact the site developers about adopting NIP-98.

Every request remains a separate decision

The comparison with 0.8.9 shows the important boundary in code. A legacy request cannot inherit a saved authentication grant. The permission lookup returns no reusable decision for this protocol, so the approval queue must ask again.

The interface offers only two outcomes: approve this request once, or deny it. It removes persistent site approval and connected-site approval from this path. Two requests from the same origin are kept as two review items rather than grouped behind one action.

Backend automation and saved relay grants cannot authorize the legacy format. The change also preserves checks for the browser frame, verified origin, active account and timestamp. Unknown clients, mismatched domains, duplicate tags, blank challenges and events carrying URL or HTTP-method tags in the wrong format are rejected rather than routed through the exception.

This separation matters because compatibility can otherwise become policy by accident. A user may decide to complete one login without granting the same site an open-ended way to request more legacy signatures later.

The release also adds optional uninstall feedback

The second visible change registers https://nostrwot.com/uninstall with the browser's uninstall URL API. Supported browsers can open that page after removal. The registered URL contains no account identifier, wallet data or tracking parameter.

Opening a page still creates a normal web request to the site, and sending feedback is optional. The release notes say only a submitted form sends the text and optional email address entered by the user. Browsers without the API skip registration, and an API failure does not stop the extension worker.

What the release does not prove

The release provides packages, source and checksums, and the diff adds tests for repeated one-time review, origin restrictions and the uninstall URL. It does not turn kind 22242 into a Nostr standard, and it does not give that format the request-level binding of NIP-98.

The practical outcome is a contained exception, not an endorsement. Users can recognize the warning and decide on one request. Client developers still need NIP-98 when a website login should bind a signature to an exact HTTP destination and method.