Bug: ndkSignerFromPayload restores correctly but sign() hangs

[alessiofx]

🐞 Bug: ndkSignerFromPayload restores correctly but sign() hangs

NDK Version: @nostr-dev-kit/ndk@2.14.29
Context: I'm using NDKNip46Signer with persistence via toPayload() and restore via ndkSignerFromPayload(...).

---

✅ Login Phase

const localSigner = NDKPrivateKeySigner.generate();

const signer = NDKNip46Signer.bunker(ndk, bunkerUri, localSigner.privateKey);
signer.on("authUrl", (url) => {
	window.open(url, "auth", "width=400,height=700");
});
await signer.blockUntilReady();

ndk.signer = signer;

const payloadString = signer.toPayload();
localStorage.setItem("currentUserSigner", payloadString);

---

✅ Restore Phase

const storedPayload = localStorage.getItem("currentUserSigner");

if (storedPayload) {
	try {
		const restoredSigner = await ndkSignerFromPayload(storedPayload, ndk);
		ndk.signer = restoredSigner;

		console.log("Signer restored successfully!");
		const user = await restoredSigner.user();
		console.log("Restored user pubkey:", user.pubkey);
	} catch (error) {
		console.error("Error during signer deserialization:", error);
	}
}

---

❌ Problem

After restoring:

• restoredSigner.user() works fine
• but await event.sign() hangs forever (no result, no error)
• restoredSigner.rpc is undefined
• so no signing request is actually sent via NIP-46

---

🔎 Hypothesis

The payload generated via toPayload() looks complete (type: "nip46", relayUrls, etc.), but upon deserialization, the internal NIP-46 connection (rpc) is not being properly initialized or persisted.

---

✅ Possible Fix

ndkSignerFromPayload(...) (or NDKNip46Signer.fromPayload(...)) may not reliably initialize rpc or call connect() internally.

---

📌 Request

Please verify that:

• rpc is initialized during payload restore
• connect() is called internally or exposed for manual reconnection if needed

Thanks for the amazing work on NDK 🙏

[esomore]

@alessiofx I migrated my app to using this instead, and it is working https://welshman.coracle.social/signer/nip-46.html

[cardugarte]

Hey @pablof7z 👋
Just wanted to bump this issue as it's a real blocker for anyone implementing NIP-46 login with session persistence.
I'm building a travel platform (Travelsats) using NDK with NDKNip46Signer and I'm hitting the exact same problem described here. The login flow works perfectly — blockUntilReady() resolves, signing works, everything is great. But after storing the payload via toPayload() and restoring it with ndkSignerFromPayload(), the signer looks valid on the surface (.user() works fine, pubkey is correct) but sign() just hangs silently forever.
As @alessiofx correctly identified, rpc is undefined after deserialization, meaning no NIP-46 request is ever actually sent to the remote signer.
This effectively makes NIP-46 session persistence broken — users have to re-authenticate with the bunker on every page reload, which is a terrible UX.
Would it be possible to either:

Have ndkSignerFromPayload() / NDKNip46Signer.fromPayload() properly initialize rpc and call connect() internally, or
Expose a reconnect() method so we can manually reinitialize the RPC connection after restore?

Happy to help test any fix. Thanks for all the amazing work on NDK 🙏

[cardugarte]

Confirming this issue — sign() hangs after NIP-46 session restore

We hit this exact problem building TravelSats, a Next.js 15 + NDK 3.0 app with NIP-98 authentication.

What we found

After extensive debugging, the root cause is in blockUntilReadyNostrConnect() — the relay subscription it creates stops routing events after the initial connect handshake. All subsequent RPC calls (sign_event, get_public_key, etc.) hang indefinitely because subManager.dispatchEvent() silently drops bunker response events.

This is not just a restore issue — it also affects the first session after the connect handshake. The get_public_key RPC call sent immediately after fromURI() resolves also hangs.

Industry validation

We researched how major Nostr web clients handle NIP-46 and found that none of them use NDK for NIP-46 signing:

Client	NIP-46 Library
Primal	nostr-tools BunkerSigner
Coracle	welshman Nip46Broker
Snort	@snort/system Nip46Signer
noStrudel	applesauce-signers

All of them implement NIP-46 with their own relay communication, bypassing NDK's subscription management entirely.

Our workaround

We built a bypass using BunkerSigner from nostr-tools/nip46 + SimplePool for relay communication, while keeping a shell NDKNip46Signer for NDK's identity/session system (profiles, follows). The actual signing goes through nostr-tools, not NDK.

However, the complexity of maintaining this dual-library architecture led us to put NIP-46 on standby for our MVP.

Suggested fix

The core issue seems to be that the NIP-46 RPC subscription needs to remain active and route events throughout the signer's lifetime, not just for the initial connect handshake. The rpc property should be properly initialized during fromPayload() / session restore, with connect() re-establishing the relay subscription.

Would love to see this fixed — NIP-46 is the standard mobile login method across the ecosystem and having it work natively in NDK would be a huge win.

[pablof7z]

Fixed in PR #383.

Root cause: NDKNip46Signer.fromPayload() did not call startListening(), so the RPC subscription was never initialized when restoring a signer from a serialized payload. This caused all signing/encryption operations to hang indefinitely.

Fix: Added await signer.startListening() to fromPayload() before returning, matching the initialization behavior of blockUntilReady() and other code paths.