I’ve not gotten fully through the spec, but why does the server hold the client’s signing key? That puts a lot of responsibility on a PDS that could be handled by the client, doesn’t it? If the client has their complete repo anyway, why can’t the PDS verify changes with a public key?
If it’s to aggregate likes, comments, etc., why not use a mailbox encrypted with the public key for unmerged data and allow the DID to decide whether or not to accept the content, aggregate it, and publish the updated repo? Other clients could choose whether or not to considered the merged mailbox when displaying to users (for example, likes could update automatically, but only accepted comments)
Basically -- to keep it simple. Holding the signing key in the PDS simplifies linearization and reduces device-pairing actions.
We spent most of the summer planning to store the signing key in the user device(s) but during a late design session we examined why exactly we wanted that, and realized the main reason was for account portability^1. Thing is, we dont need the primary signing key to be local for account portability; we just need a recovery key that allows the user to assign control away from the PDS later. So we switched to a server-held signing key, but we kept in the architectural pieces that make client-held signing keys possible, in case we want to explore that again in the future.
^1 We're interested in end-to-end encryption but that's not what the signing key would accomplish and will need to be developed later. Hopefully we haven't painted ourselves into a corner for that part of things.
Seems to suggest the signing key is all that’s needed to change the keys for a user? I was expecting it to say the recovery key could be used for that (which only I have).
If it’s to aggregate likes, comments, etc., why not use a mailbox encrypted with the public key for unmerged data and allow the DID to decide whether or not to accept the content, aggregate it, and publish the updated repo? Other clients could choose whether or not to considered the merged mailbox when displaying to users (for example, likes could update automatically, but only accepted comments)