It’s solvable if you’re willing to self-host your PDS.
But I’m skeptical of the attempts to make a PDS an “everything account.” Why should you use the same PDS for your social media posts and your git repos and your blog posts? Seems like we need to get better at locking things down in practice before that kind of centralization?
Even with GitHub we don’t hand over our private keys to the GitHub server, though.
When I commit to my repos the commits are still signed by the private key that lives on my computer. Someone could take over my GitHub account and they wouldn’t be able to sign commits with the private key on my PC.
They could technically add a new public key and sign new commits with that key, but I could cryptographically point to the change and show that the key changed at time of takeover and disavow it.
If you're not signing them then hosting on GitHub gives GitHub the ability to do arbitrary commits in your name. The repo's HEAD is whatever GitHub says it is.
I'm probably in the minority though.
For the current moment though you can just create an atproto account without creating a bluesky account. Tangled for example supports this on their site by creating one for their PDS and you can always move to another PDS in the future.
The over-arching idea isn't that your code is tied to your socials but rather that you can have a bunch of disparate services that you can interlink over a common identity layer and that those services are only loosely tied to the people/orgs hosting them but could be trivially hosted by anyone else.
Then create separate accounts?
If my DNS provider messes up, I revoke their DNSSEC keys and point my domain to a different provider.
Domain registration should be national public infrastructure.
> Your PDS operator can post as you, like things as you, follow people as you, and it would be cryptographically indistinguishable from your real activity. The signatures are valid.
Your domain name owner or DNS provider cannot redirect your domain name to a different server and cryptographically impersonate you.
It's not exactly the same thing but it's close.
In a social protocol or context, I would expect a private key to be in the private control of the individual, such as when someone uses their private key to sign an email or git commit.
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.
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.
I do agree they're not the same but the trust and risk are very similar.
They are similar in that: jerks can be jerks. But one of the jerks I've trusted for 30 years and I hardly know the the other jerk.
Socially whether you can explain off that your PDS acted maliciously or that it was hacked or whatever is a different story but if you keep recovery keys for your DID you can take back control and undo everything your PDS did that you didn't authorise pretty trivially. The UX for it needs to be improved but technically the process is super simple/straight forward.
And those recovery keys provide a mechanism for declaring "hey i didn't do this I was hacked" on top of specific events but nothing for taking advantage of that cryptographic opportunity has been built out yet.
The author's concern seems to be more focused on impersonation
And for lower bandwidth tasks, Tor Onions can't be beat. Just make sure to use 2fa on services you offer to keep the trash out. Things like fail2ban don't work the way you intend.
DNSSec is used to prevent unauthorized stealing of domains. Furthermore, if someone does steal one domain you own, they don't steal all your accounts across all domains. If they take over your hosting, that's a fixable problem -- you just repoint the domain.
Now, having said that, I designed the Safebox exactly to prevent these scenarios from happening, and create an actually solid foundation for decentralized social networking, AI workloads, etc. If anyone is interested, probably the best link to begin reading about it is: https://safebots.ai/about (If you do, I'd love to hear your thoughts)
You don't even have the frameworks that are available to protect domains. (Domain lock, transfer, etc.) And registrars are regulated by laws and frameworks in ways ATProto hosts aren't. Don't get me wrong, if a registrar transfers your domain due to a social engineering attack on the registrar, then you might lose it (an attacker almost did this to me once via a SIM swap, and I had to call GoDaddy to prevent the transfers). But that's not the same as, say, hacking the web hosting server.
In any case, tptacek, Safebox is supposed to solve these actual problems, by making sure no one can actually get into the box (no ssh, etc) so it's a "neutral ground" that no one can really "own", "redirect", steal keys or impersonate you. If you read https://safebots.ai/about you'll see what I'm talking about. If you do, I'd love to read any feedback you might have, given your background in security!
And regarding DNSSEC... if your domain is taken by the registrar (court order, ToS violation, etc.) or a government that can command the parent TLD to act, they can just revoke your old key and transfer the domain to someone else (or setup a placeholder under their own DNS) and now your protection and all concept of ownership is completely gone without your consent. This happened a few years ago with Epik seizing the soyjakparty and kiwifarms domains, including their hosting from a subsidiary company Terrahost... and KF has never even lost a lawsuit, but there are some specific people that really don't like them, and have gotten adept at claiming ToS violations via every possible company that touches them in order to try to make them go away.
Uh, no.
I can legally shoot and kill intruders due to castle doctrine and stand your ground laws in my physical home. And legal invasions require being in front of a judge and a search warrant.
A domain can be seized for 'terms of service' (aka kangaroo court) reasons. Stand your ground nor castle doctrine doesn't apply to your digital house.
How many houses were actually seized, repossessed, commandeered with "eminent domain", slowly taken over via "adverse possession", encroached on with easements and air rights, and whatever else? Versus how many domains?
There is no violence on the internet. You can't shoot intruders. And that's a great thing.
Put in legal terms, you do NOT have this level of ownership to your house... and you certainly do not have sovereign immunity on your land: https://en.wikipedia.org/wiki/Allodial_title
Usually the best you can get is this: https://en.wikipedia.org/wiki/Fee_simple
You probably have something more like this: https://en.wikipedia.org/wiki/Freehold_(law)
What you are describing is more like the king of England being able to shoot people on his own property, and have full sovereign immunity (in theory, I mean recently a British prince was arrested on allegations of far less).
That means if you are a home invader, I can legally shoot and kill you. There'll be an investigation, but both statutes are affirmative defenses to killing.
Its not that I want to, or look forward to it. I don't, and I hope I never have to. But I will, if I'm forced.
Bluesky Social, PBC runs a PDS service (bsky.social) for free, there are a number of free public alternatives, and thousands of users self-host.
Self-hosting your own PDS can be done with Raspberry Pi or $5/mo VM and requires very little work. It runs in a Docker container with SQLite.
They hold the keys for your DID. If they don't allow you to move to another PDS, you can't move. The original theory was that you'd hold the private keys, but that's something that would hugely limit adoption so they decided to hold the keys themselves.
In terms of moving your backlog of posts to a new server, part of the issue is liability (not merely legal liability, but reputational as well). When you have a user on your platform and they're posting stuff, you're moderating them in real time. If they turn out to be a horrible troll, you've get the reports. Let's say a horrible troll has been on EvilServer and EvilServer has been ignoring the reports against them. They now want to move to your GoodServer and bring all their post history with them. As an admin of GoodServer, you can't see that everyone has been reporting this troll for years. They're now moving over lots of horrible, inflammatory, potentially illegal posts to your server.
Moderation tools arent limited to specific PDS's, labels are public. If an account has received many reports it will have been labelled by Bluesky's moderation account and other independent labellers. A PDS can check against these before allowing an account to migrate if they choose to. I'm not sure any are currently doing this, but this is something that can absolutely be improved in current implementations, not an inherent limitation of the architecture.
*requires your own PLC key, which the vast majority of users do not have, protonmail has good prior art here (imo)
It's completely straightforward and it works. Tens of thousands of users are doing it successfully.
This is just how the web works, and there is no easy around it without losing features people care about. Sure, you can do client-side encryption and pretend serve can't see the plaintext, but it's just a theatre, see Hushmail incident for example.
And having people export uber-key by default is pretty terrible idea. Sure, allow advanced users (like post author) to do it. But for the common person, the exported key is just another way to get account compromised, via malware or backup provider hacking. Or if they are not backing up stuff, then the key will get lost next time they upgrade.
Keeping a private keep on the client to sign your activity is a fundamental cryptography practice.
If you use a private key to sign your emails or git commits, it’s not security theater.
If you were to have to upload your private key to GitHub or your email provider, that would be severity theater.
> Is author new at the whole web thing?
Unnecessarily mean comment.
Well, apart from using a separate email address for every single "provider"?
(Spoiler: there's no way I'm going to sign into your service with a shared email ... you get <youservice>@<me>.com)
CAs have to prove they're not faking certs through the certificate transparency logs, there's no such limitation on Bluesky.
A more apt comparison is a shared host that does certificate management for you. Those are also often considered less secure, of course.
is a heading
edit:
>On ATProto, your PDS doesn't just store your Bluesky posts. It stores everything.
>Not just your Bluesky account. Your ability to post, commit, publish, or interact across every ATProto app.
>The repo data itself isn't the issue. It's all public anyway,
>An attacker, a state actor with a warrant, or a rogue employee doesn't just get read access. They get the signing keys
Being able to tell who wrote something doesn't imply irrationality, panicking, or a reaction to new technology.
> like UFO sightings in the 1950s.
UFO sightings stayed confined to the 1950s and were a reaction to new technology?
Or were the UFO sightings in the 1950s the only UFO sightings that were a reaction to new technology?
I'm not sure how this being clarified will be able to explain how identifying the writer of text is the same as a UFO sighting in 1950, but I'm open to it, I try to stay rigorously rational (c.f. X does not imply Y in first pull quote)
> If ever it is still possible to "tell" AI writing, it soon will not be.
Why not?
n.b. I quit my job at Google to build an AI client and have been working on it full time for 3 years. I love AI. I don't think there's a rational argument that justifies the idea it's better to never opine the author of some writing was AI, and the arguments offered here are particularly weak, at their face. As an opinion, solely? Fair enough.
But I say: who cares? The substance and the authenticity are what count. This article made some interesting points, and it was signed off on by a human author. Personally, I'm no more interested in whether the author used AI to produce the text than in whether they used a dictionary or thesaurus, as long as they stand by the words.
This whole "debate" has the feel of religion to it. I'm consistently surprised that there's so much woolly, unfalsifiable thinking on this subject. And here, of all places.
This is false, it is trivial to find humans with 99%+ accuracy[1] and there is a well-known service with 99%+ accuracy when analyzed by 3rd parties with no affiliation.[2]
> people are just guessing based on what they see in an unscientific way
As we see above, this is just guessing in an unscientific way. :) It's important to be rational! We all agree on that. :)
FWIW it did used to be true that the 3rd party services were junk. And I don't support the idea of humans just winging it when there's consequences. The case we're in is about the most mundane and consequence-free, the vast majority of us use AI daily and we're commenting on an internet aggregator that is aggregating a blog article.
[1] People who frequently use ChatGPT for writing tasks are accurate and robust detectors of AI-generated text - https://aclanthology.org/2025.acl-long.267/
[2] Artificial Writing and Automated Detection” - https://bfi.uchicago.edu/insights/artificial-writing-and-aut...
Not even sure why the PDS would require our signing key that just seems very sloppy to me. As you can tell I know very little about atProto, and I did participate in the development of the DID standard and I am dismayed to see such an inelegant solution in such a promising protocol.
So if the worst case scenario presented in this article took place where a PDS was falsifying information and pretending to be you, you could presumably somehow revoke the child key that you provided to the PDS. I'll have to look more closely at this
You could even publish a signed selective retraction (delete the fake posts or mark them as fake) with proof that you control the key 1 level above the key that posted them