window.nostr.wot: a shared Web of Trust for browser apps

what the interface exposes

the proposal adds a wot object under window.nostr, alongside the familiar browser signer interface. Web of Trust queries and signing remain independent capabilities

an application can ask for hop distance, mutual follows, a path through the graph, or a relative score. it can batch those questions or filter a list of authors within a chosen distance. status methods describe whether the graph is ready and whether queries are local, remote or a combination

for example, getDistance(target) returns 1 for someone i follow, 2 for a follow-of-follow, and null when the target is not reachable in the available graph. filterByWoT(authors, 2) gives a feed a direct way to request that two-hop neighborhood

that distinction between an answer and missing information matters. null does not mean someone is untrustworthy. the extension may simply lack a path to them

a graph belongs to its user

i wanted applications to share access to a user-controlled graph without each becoming the authority over that user's relationships

the API is read-only. a page can query it, but it cannot use those methods to rewrite the graph or change the extension's scoring configuration. profiles need isolation so switching identities does not expose one account's graph through another

queries also reveal information. asking for a full path exposes intermediary public keys, so the draft requires permission for that method. remote queries reveal interests to the oracle serving them, and the proposal calls for disclosing that behavior. local and remote modes have different privacy implications even when the result looks the same

a score is a relative signal

the proposal leaves the scoring formula to the implementation. distance and the number of paths can be useful signals, but an app should not interpret a value such as 0.7 as a measured probability that someone is honest

following someone is a relationship, not a security guarantee. graph coverage, stale follow lists and manipulated relationships affect the result. i see this as information a user can apply to filtering and discovery, with a way to widen the view when needed

keeping that boundary clear also leaves room for different implementations. applications can use the common query surface without forcing every extension to adopt one universal reputation formula

where it stands

the original issue, #2236, remains open as of October 12, 2026. it is an optional draft extending the NIP-07 namespace, not an accepted NIP or a capability every browser signer provides. its last recorded update is still February 24

the Nostr WoT extension is the reference implementation linked by the proposal, with documentation for the project. implementers should check the current API and permissions rather than assume that every part of an evolving implementation is identical to the February draft

the idea remains small: give an application a consistent way to ask about the user's graph, while keeping control of that graph with the user