But if we have an nsecbunker running we can still use it, right?
Since this is aimed at new users who still need to create an account, them already having an nsecbunker running isn't really reasonable. Like nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s said in another reply, other clients and service specifically there to run bunkers are the ones who will provide the backend.
The library uses NIP-89 (application handlers) to find nsecbunkers that support this sort of flow and then allow the user to select between them when creating an account.
Discussion
If you’re running an nsecbunker you probably won’t be creating a new account for yourself, right?
But I am going to add some UI to allow you to input your npub or nip05 to sign in (call the connect) method. It’ll still be up to the client itself to handle signing using nip-46 remote signing from that point forward though so I don’t know how useful that actually is.
Why? Your polyfill is replacing window.nostr, why would the client still need to implement nip-46?
Wouldn’t the client need to still know to send events for signing to relays so that the bunker could sign them?
Isn’t that what your nostrignite does?
Client calls window.nostr.signEvent
Nostr ignite gets the signature via nip-46 and returns it to the client
It doesn’t do that yet. Just creates a new account and calls connect and returns the pubkey to the client.
That’ll be a fairly easy add though.
Don’t want to end up completely rewriting NDK here though. 🫠
Why not? Rewrite it in Rust.
😬 That is definitely not the way to ship in 2 weeks™
Also there's already: https://github.com/rust-nostr/nostr
Shouldn't that be the library to implement nip-46 in Rust?