This is precisely what we do for the NameSys Resolver. In CLI environment however, it would still require the user to either sign the message ‘offline’ and paste the signature manually, or import their key to .env. Both are not ideal… unless someone wants to build a deeplink redirectooor to browser and back to CLI for signing. It may exist already but we haven’t checked.
Seems like I may have misunderstood the comment and @0xc0de4c0ffee corrected me offline.
Did you mean dev3.eth and its owner? This wouldn’t help against account compromise since hijacker of nick.dev3.eth can always generate a new local signer and get it approved by the owner of dev3.eth. Only way to escape this situation is if nick.dev3.eth has an on-chain owner to validate against. Without external on-chain reference to nick.dev3.eth, it’s a circularly referencing system. One possible way is to issue a time-lock on validating a new signer in our CF approver, i.e. a user must wait X amount of time before validating a new signer; this solution can be integrated in more serious implementations. dev3.eth is a simple prototype for developers to play with and possibly extend to better versions.
P.S. We do precisely what you suggest for NameSys Resolver. Owner of each domain.eth has their on-chain owner who can validate the signer. In dev3.eth that’s not the case since subnames are off-chain.