Yes, it can be on either direction.
Are you interested in the signer to client flow? That flow never made sense to me; curious about it.
Discussion
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.
perfect, it fits right on
you should participate in the nip discussion then, especially if you are confused with it
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).
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
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.