To explain why the comment below is correct, you are right that the other instance couldn’t get your password. They don’t need that to create a post/comment that is supposedly sent from an account though. Those aren’t cryptographically signed or anything like that. It just says “this user sent this message”.
I don’t even think there is a way you could do this with some kind of cryptographic signature, unless it basically just sends an encrypted message to the home server and it verifies it, which then we have the same issue we started with of relying on a single server. I guess every message could be sent with a key, which can be disputed later. If the home server is unavailable, the message is sent, but it can later say that it’s a forgery when it comes back online. It’s not a perfect fix, but it’s the only way this could even possibly work I think.
User registers at home server. Client generates pair of public and private keys, password provided by user during registration is used to encrypt (symmetrically) private key. Public and encrypted private keys stored on home server and then propagate over federation to other servers. Obviously propagation takes some time. Just like anything that uses ActivityPub (don’t know why I have to say it explicitly). Original private key not recorded anywhere. User initiates login on federated server. Federated server challenges user by providing encrypted private key and challenge phrase. User uses password to decrypt private key on client side and signs message with challenge phrase. Server uses public key to validate signature and phrase. User logged in. User creates signed post. All federated servers have copy of public key so they can check authenticity of origin of post.
I’m not saying it’s easy or perfect. I have no idea how feasible it is in current architecture. Probably there’s a smarter and more secure way to do it. I’m also not a team of security engineers who is getting paid to get this kind of things designed professionally.
My point is that, I think, it’s more of willingness issue than technical.
To explain why the comment below is correct, you are right that the other instance couldn’t get your password. They don’t need that to create a post/comment that is supposedly sent from an account though. Those aren’t cryptographically signed or anything like that. It just says “this user sent this message”.
I don’t even think there is a way you could do this with some kind of cryptographic signature, unless it basically just sends an encrypted message to the home server and it verifies it, which then we have the same issue we started with of relying on a single server. I guess every message could be sent with a key, which can be disputed later. If the home server is unavailable, the message is sent, but it can later say that it’s a forgery when it comes back online. It’s not a perfect fix, but it’s the only way this could even possibly work I think.
User registers at home server. Client generates pair of public and private keys, password provided by user during registration is used to encrypt (symmetrically) private key. Public and encrypted private keys stored on home server and then propagate over federation to other servers. Obviously propagation takes some time. Just like anything that uses ActivityPub (don’t know why I have to say it explicitly). Original private key not recorded anywhere. User initiates login on federated server. Federated server challenges user by providing encrypted private key and challenge phrase. User uses password to decrypt private key on client side and signs message with challenge phrase. Server uses public key to validate signature and phrase. User logged in. User creates signed post. All federated servers have copy of public key so they can check authenticity of origin of post.
I’m not saying it’s easy or perfect. I have no idea how feasible it is in current architecture. Probably there’s a smarter and more secure way to do it. I’m also not a team of security engineers who is getting paid to get this kind of things designed professionally.
My point is that, I think, it’s more of willingness issue than technical.