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.

Reply to this note

Please Login to reply.

Discussion

But if we have an nsecbunker running we can still use it, right?

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.

Wait, I thought it would replace window.nostr with a popout thing that connected to NIP-46!

If it just creates an account then I don't like it.

One step at a time! This is how we actually deliver in 2 weeksâ„¢.

Signing coming next.

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?