Implement arti hsc subcommand for managing hs-nickname -> HsId changes
If a service <hsid1>
running in "restricted mode" rotates its identity keys
(<hsid1>
-> <hsid2>
), on the client side, client/<hs-nickname>+<hsid1>
needs to be copied to client/<hs-nickname>+<hsid2>
for the duration of the
transition period. After the transition period, client/<hs-nickname>+<hsid1>
can be removed. We can provide an arti hsc
subcommand for handling HsId
changes, but it will need to be run manually.
(This is inconvenient but unavoidable: the nickname -> HsId mapping needs to be
manually updated regardless of whether it's encoded in the ArtiPath
or stored
separately.)
We need to provide an arti hsc
subcommand for managing HsId changes, and decide
how long old <hs-nickname>
-> <hsid>
mapping is allowed to exist for.
Ideally, we'd provide an arti hsc
command for garbage collecting keys that
haven't been used in N
time units (where N
is a command-line option).
However, we don't store last modified/last accessed timestamps in the
keystore, so this will require a bit of design/discussion (one option would
be to put these timestamps in the comment of the key)