@evanprodromou Is there a reason you didn't consider using https://github.com/silverbucket/webfinger.js which is modern, maintained, definitely works in browsers, and has zero dependencies?

@evanprodromou@socialwebfoundation.org I was curious what your package does that mine doesn't, so I threw qwen at it. I've cut out much of the fluff, but the gist (feel free to skip it):

What the package does that NodeBB doesn't

• rel query parameter — passes rel to the server for server-side link filtering (NodeBB always fetches all links and filters client-side).
• First-class aliases and properties accessors (NodeBB buries them in _raw).
• link(rel, type) selector with exact media-type matching (NodeBB filters inline with assertAccept substring matching).
• Frozen/immutable result objects.
• Zero dependencies, native fetch.

What NodeBB does that the package doesn't

• Caching (positive 24h, negative 10min) + split-domain cache-bypass under strict.
• 5s timeout.
• Content-type validation with an application/octet-stream → JSON.parse fallback for non-compliant servers (package just calls res.json() and throws).
• Subject handling: fixes missing acct:/did: scheme, extracts subjectHostname, computes splitDomain.
• strict mode (rejects cross-domain subjects).
• actorUri extraction (rel=self filtered by accepted ActivityPub types) and publicKey extraction.
• false-on-failure semantics (callers do result || {...}).
• Hostname round-trip validation (new URL('https://'+host)/ check) and cache-key normalization.

Latent bug in the package

It uses static URL.parse() for URL inputs — deprecated since Node 10 and slated for removal. It still works on this Node 23 build, but it's a ticking time-bomb on the Node versions it targets (22/24/26).

It reads like NodeBB's webfinger parsing is more battle-tested because I've had to handle funky webfinger responses from slightly out-of-spec servers.

There's potential for me to use your package as a low-level fetcher though.