> The purpose of signing your emails or commits is to provide a good indicator that it actually came from you, not someone who managed to get access to your email account at the time.

This is true and it's still true in the ATProto ecosystem but in a different context.

It asserts that events and records are authored by your PDS, not by you specifically. Which is certainly closer to the intent of TLS certs.

And technically you can maintain a PDS proxy that can only host, broadcast events, and receive content but that doesn't have any keys or signing capabilities.

Then you can have a local PDS that does your signing and sends signed events and records (basically signed state updates) to the PDS proxy to actually emit to the network. This then allows you to lock your keys behind a hardware key to better lock everything down. Of course there are trade offs to this. If it requires physical auth then it can only work on one device at a time or you have to self host it homelab style at which point it might just make more sense to host the PDS yourself anyways.

There's a project thats working on this very thing but I've not kept up with it and I can't remember what the name of it is. If any ATproto people in the comments knows the name/link feel free to reply under this to enlighten me + everyone else.

If you use your private key to sign your commit, I don’t see how your PDS can impersonate it. There are different layers here. Your commit is still signed by you and non-impersonatable by the PDS operator. But the ATProto layer signing is under control of the PDS. So in that case you’d see either unsigned or differently signed git commits being reported at the ATProto layer as by you.

That seems entirely normal. The PDS handles ATProto actions but it cannot modify the git signature (obviously!). It’s no different than the fact that GitHub can post that you’ve committed a “verified” badge commit by adding a new signing key to your account and signing new commits with it.

The storage entity can always claim power over this by reporting a new key and signatures with that key. Seems entirely normal.

This is why your DNS hosting provider, despite not being the "current owner of the domain", being able to impersonate your site (terminate a cryptographically secure TLS session) with your customers is a similar problem.

I do agree they're not the same but the trust and risk are very similar.