[bnewbold]

all public account content is in a "repo", commits to the repo are signed, and the identity resolution mechanism gives anybody the current/active signing key.

the most direct analogy is to signed git commits. this is an intentional design decision compared to signing individual messages/posts/etc. A "proof" for a single record in the repo is the commit, the record, and the chain of merkle tree nodes connecting the two.

[verdverm]

Who signs new nodes in the tree? The server or the content creator? What prevents a server from creating content for anyone?

So you can confirm it was not changed, but cannot confirm that the original addition came from the real person?

I don't see anything in the docs that talk about cryptographic signatures or key management.

[goykasi]

From what I can tell after digging into the code, the server is responsible for signing everything. I was really hoping that users would have more control in regards to this. I have a similar concern, what prevents the server from publishing without the users consent?

Also, I keep seeing discussion about being able to move identities to a new server, but to do that, you need to update your corresponding DID Document -- currently published to https://plc.directory/. Again, that has to be done with the sigining key. What if a server refuses? Is the user stuck and forced to recreate the account/history somewhere else?

[jsmith45]

There are two keys that can be used for DID updates. One is the signing key that the publishing server may also control, one one is the recovery key. If a content server goes rogue, the recovery key can be used within 72 hours to retroactive undo changes made to the DID (if the server did that).

If the server just maliciously messed with your data repository, you just use the recovery key. If the malicious content server did not try to rotate the recovery key, you can just use it to reset the signing key, regardless of if the content server rotated it. If it did malicious try to rotate the recovery key, as long as you notice within 72 hours, you can fork a new DID history from some state that was current within the last 72 hours that has your old recovery key.

Either way, you use the recovery key to rotate the signing key, to something you control. Now, you can repoint your DID to a new content server, upload your unadulterated post history to it.

Also, the core of the protocol does not strictly require that the content server have your publishing keys. In theory a client can create new posts, sign them and upload them. This will mean that certain API methods that exist that do things like add a new post won't work, which is theoretically fine if you only ever want to post from fully trusted clients that could be given access to your signing key, create a new commit, and upload it.

Also it is not yet clear if all servers will allow such usage. In theory a content server could refuse to host the data repositories for users if it lacks the signing key for the user.

Footnote: These content servers are formally called Personal Data Servers. I used content servers throughout this post to be clear that I am not talking about plc.directory or other such ancillary servers.

[afiori]

> I have a similar concern, what prevents the server from publishing without the users consent?

I suspect that the solution would be to run on a trusted server, maybe your own.

[verdverm]

most people won't want to manage their keys, the UX around that sucks, so federation only in name?

[afiori]

"most people don't manage their keys and use semi-trusted intermediaries of their choice" sound like a central example of federation.

"Everybody is their own server" is decentralization