these are all different things.
The reason for a remote signer COULD be the airgapped security consideration you mentioned; but how many hardwarewallet-type signers that are currently in use that work that way in Nostr are you aware of?
Most are, in fact, internet connected, but then added benefit is that you can reduce attack surface, like amber is doing for example.
At the same time, the added value can also just simply be the fact that only 1 thing has your keys instead of having to trust all the clients that you use with your keys (+ the need to handle those keys to load them into the clients in the first place).
Before i go into the reason why i would want to burden the signer with publication, please note that im not saying that should, all i am proposing is a silly little flag such that clients know that they are; the current mode of operation where they don't would still just exist.
As for the reason:
Im designing this ''Trust Extended Permissions Protocol'' (TEPP) to create permissioned Nostr environments for (example/mostly) children. This system can run at many places at the same time (clients, signers, even relays although not super likely).
It should work well enough in the current paradigm, but signers would still be fairly limited in what they can control for; mainly the stuff related to what relays events are send to (which is something the system does allow you to determine). That means that that part would have to be implemented by the clients.
Thats not the end of the world, but from a TEPP perspective, it would make things easier and better if a bunch more effort is put into a hefty TEPP complient signer that also handles publication, such that it matters a whole lot less if clients even implemented TEPP in the first place; and subsequently it would allow for clients to have a half assed TEPP implementation, but when paired to this ''super signer'', would still basically cover all the bases.
For more context:
View article →
