Nostr Web Client

In general, I want to understand the current specification first.

I did a Nip46 remote signer implementation before the "bunker era" which is now broken. I have several ideas for a new thing but find the current spec unclear and ambiguous.

From a client UX perspective, I find anything with manually copying or scanning not acceptable. So, my new remote signer (service) should be able to be integrated into an automated flow.

PABLOF7z 1y ago

perfect, it fits right on

you should participate in the nip discussion then, especially if you are confused with it

Reply to this note

Please Login to reply.

Discussion

Chris 1y ago

I am still trying to understand the discussion you have. What I am not understanding is:

Why has the bunker connection token the remote_user_pubkey? I initially thought that the signer side would have its own keys for communication that don't need to be the same than the credentials a client is requesting (e.g. via get_publik_key).

PABLOF7z 1y ago

no, the signer's key is only used for commands meant for the signer (i.e. create_account)

I wrote a simplied spec from the one being currently discussed; hopefully that clears it since it doesn't even mention that the signer can have a pubkey of it's own until those commands are introduced

https://gist.github.com/pablof7z/dc5b08c3e39cb73512473a53f5f83b48

Chris 1y ago

Thanks for the link and your patience.

I think I get the current concept. But it still feels odd to me to "use the user's key for communication". Does that not make the method get_public_key obsolete?

I know that is another discussion as the one currently going on.

PABLOF7z 1y ago

The get_public_key command makes no sense 😅

Chris 1y ago

Then it really is a slightly different approach as with NIP07, where the get_publik_key totally makes sense.

Thank you for clarifying.