Hacker News new | past | comments | ask | show | jobs | submit login

If you look at the imported posts, they have a badge that says the date they were imported and says the date on the post is unverified.



Yes, but this badge is generated at their Appview index layer and not at your PDS.


If you are syncing data from another PDS, there is no way to verify that posts have an accurate date, unless you have some central ledger which is antithetical to allowing self-hosting and being distributed.


Correct. The trade-off here is on Bluesky you can delete or re-order your posts which you cannot do on a network with strict message ordering. Your PDS webmaster can also rewrite your messages for you if they become unhappy with your messaging.


This isn't quite true. Your PDS can't rewrite your messages: all messages are signed with a key unique to your account.

That said, the PDS is effectively also your private key custodian. Most people who aren't nerds are happy to let Bluesky PBC manage their keys. But if that's your threat model, you should absolutely move to a self-managed PDS.

The protocol also actually allows you to manage your keys differently. You could in theory have a "read-only" PDS, and generate all your posts locally using a local key (conceptually much closer to a crypto wallet.)

In that scenario, the validity of posts as originating from a known identity is extremely strong.


Yes, and what if they had a tab in the Bluesky app where you generated a keypair, registered the pubkey at your PDS and then began signing messages in the app? You could rotate keys on demand and update the PDS every time you make a new one.


Originally that was the design. We just felt it wasn’t feasible as the primary operation.

The PLC registry supports an override key for adversarial migrations, which was our chosen alternative


I don't think it should be the primary operation, not with the scale that Bluesky has achieved. We need this in the Bluesky App so a handful of p2p weirdos can feel they are authentically using a distributed social platform without caesars and all of that.

I'll look into the registry override too, maybe I can hack something together around that.


Yeah but if you lost your phone you'd be screwed.

There's ways around it... the identity mechanism supports multiple keys so you could have a backup in escrow.

But most people don't want to worry about key management at that level. Hell, I know exactly how everything works, and key management still scares me. The consequences of a mistake are huge.


Yes, that key is screwed because it's lost, stolen, at the bottom of the river, etc. But this is when you generate a new key and store that pubkey at your PDS so the Appview can find and index your new posts from your new phone. It's the same thing that happens when I reinstall Debian on my Thinkpad and upload a new ed25519 pubkey to Github so I can push again.

Edit: or we could backup the key.


Your PDS webmaster has a signing key for your repo, because they for all intents and purposes are you. That's the trust structure of how PDS' are setup. If you don't trust someone else to modify your repo don't give them your private (sub)key.

The fact it's a subkey means that you are also able to rotate the key that the PDS has access to and modify your repo back to pre-defaced state if need be.


Exactly, this is the benefit of having a Bluesky!

Imagine if Github worked this way, then I wouldn't have to worry about storing my ssh keys on my local machine. Imagine the possibilities if Github could pull my repo instead of me having to go through all that darned trouble of pushing it.


Take snapshots with the Internet Archive and have that be canonical/source of truth?




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: