Is your feature request related to a problem? Please describe.
Current handling of public key changes is a bit incoherent
Describe the solution you'd like
atServers for some time have been detecting public key changed events and storing them. The simplest, most secure and maintainable way to deal with public key changed events is I believe the following:
(i) When atServer @alice detects that @bob's public key has changed, it blocks any attempt by @alice to communicate with @bob until @alice's owner executes a command to unblock @bob
(ii) We augment at_activate to provide that "unblock" command (and of course make it available via SDK also)
(iii) Additionally we no longer cache other atSigns' public keys in client programs except perhaps in memory for a few minutes as a performance optimization
Additionally implement in atServer the ability to rotate the core keypair (new publickey@alice has to be signed with the private key corresponding to the old publickey@alice). Note that there is more work to do client-side to handle this cleanly in all use cases
Describe alternatives you've considered
No response
Additional context
No response
Is your feature request related to a problem? Please describe.
Current handling of public key changes is a bit incoherent
Describe the solution you'd like
atServers for some time have been detecting public key changed events and storing them. The simplest, most secure and maintainable way to deal with public key changed events is I believe the following:
(i) When atServer @alice detects that @bob's public key has changed, it blocks any attempt by @alice to communicate with @bob until @alice's owner executes a command to unblock @bob
(ii) We augment at_activate to provide that "unblock" command (and of course make it available via SDK also)
(iii) Additionally we no longer cache other atSigns' public keys in client programs except perhaps in memory for a few minutes as a performance optimization
Additionally implement in atServer the ability to rotate the core keypair (new
publickey@alicehas to be signed with the private key corresponding to the oldpublickey@alice). Note that there is more work to do client-side to handle this cleanly in all use casesDescribe alternatives you've considered
No response
Additional context
No response