NDKNwc.fromURI always throws 'pubkey not set' in browser

[ekzyis]

Description

The URL constructor in the browser parses URLs differently than in node.

With the current implementation of NWC in NDK, I don't see a way to get NWC working in the browser using NdkNWC.fromURI. I always get pubkey not set because NDK uses

pubkey: u.host ?? u.pathname

instead of

pubkey: u.host || u.pathname

here:

ndk/ndk/src/nwc/index.ts

Lines 94 to 110 in 6b3ea8b

	static async fromURI(ndk: NDK, uri: string): Promise<NDKNwc> {
	const u = new URL(uri);
	// validate protocol nostr+walletconnect
	if (u.protocol !== "nostr+walletconnect:") {
	throw new Error("Invalid protocol");
	}
	const nwc = new NDKNwc({
	ndk,
	pubkey: u.host ?? u.pathname,
	relayUrls: u.searchParams.getAll("relay") ?? [""],
	secret: u.searchParams.get("secret") ?? "",
	});
	return nwc;
	}

For example, if I use nostr+walletconnect://:

node: u.host ✅ | u.pathname ❌

$ node
Welcome to Node.js v20.18.0.
Type ".help" for more information.
> new URL("nostr+walletconnect://2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88")
URL {
  href: 'nostr+walletconnect://2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88',
  origin: 'null',
  protocol: 'nostr+walletconnect:',
  username: '',
  password: '',
  host: '2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715',
  hostname: '2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715',
  port: '',
  pathname: '',
  search: '?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88',
  searchParams: URLSearchParams {
    'relay' => 'wss://relay.primal.net',
    'secret' => '2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88' },
  hash: ''
}

browser: u.host ❌ | u.pathname ❌ (includes //)

If I use nostr+walletconnect::

node: u.host ❌ | u.pathname ✅

> new URL("nostr+walletconnect:2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88")
URL {
  href: 'nostr+walletconnect:2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88',
  origin: 'null',
  protocol: 'nostr+walletconnect:',
  username: '',
  password: '',
  host: '',
  hostname: '',
  port: '',
  pathname: '2eb69717e2dac6c052ba7ab8cb164c5886c1ddaf3161b53e72d31cd8695a7715',
  search: '?relay=wss%3A%2F%2Frelay.primal.net&secret=2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88',
  searchParams: URLSearchParams {
    'relay' => 'wss://relay.primal.net',
    'secret' => '2683ed09282e1b0d1545dd39957add77ce489ca37fd5fbb8f7b2e6b039272b88' },
  hash: ''
}

browser: u.host ❌ | u.pathname ✅

Since in both cases, the browser will set u.host to the empty string, the pubkey is never set in the browser. Using || instead of ?? fixes that at least for the nostr+walletconnect: case.

Additional context

Alby replaces the protocol with http:// to get consistent URL parsing behavior in node and browser for any NWC prefix, see here. I recommend to do the same but I didn't want to change this code more than necessary to get it working using at least one prefix before feedback.

Environment

NDK version: v2.10.5
node version: 20.18.0
Brave version: 1.62.165 Chromium: 121.0.6167.184 (Official Build) (64-bit)
Firefox version: 132.0.2 (64-bit)

[ekzyis]

FYI, there has been a breaking change to URL parsing in Chromium-based browsers in the Oct 15 release:

Support non-special scheme URLs

Previously, Chrome's URL parser didn't support non-special URLs. The parser parses non-special URLs as if they had an "opaque path", which is not aligned with the URL Standard. Now, Chromium's URL parser parses non-special URLs correctly, following the URL Standard.

-- https://developer.chrome.com/release-notes/130?hl=en#support_non-special_scheme_urls

Apparently, they didn't follow the URL standard but do now. However, this doesn't seem to be limited to Chromium-based browsers since the Developer Edition of Firefox also included breaking changes, see stackernews/stacker.news#1590 (comment).

Thanks to @riccardobl for investigating this discrepancy between URL parsing between browsers and even between recent versions of the same browser.

See https://docs.google.com/document/u/0/d/1LjxHl32fE4tCKugrK_PIso7mfXQVEeoD1wSnX2y0ZU8/mobilebasic?resourcekey=0-d1gP4X2sG7GPl9mlTeptIA#heading=h.a67ulu2yrl9p for more details.

[ekzyis]

Same issue exists with the signer for NIP-46