HN user
for account-associated encryption, what it should do instead is to generate a dedicated file encryption key for each backup, and encrypt said key with the account's passkeys. Each time the user adds a new passkey, it should save an additional copy of the backup's key encrypted with the new passkey. This way you can have multiple redundant passkeys that can decrypt the backup. This is basically how age's multi-recipient encryption works.
I recently whipped up a bare-bones PWA wrapping Typage[0] into a quick-and-dirty tool to encrypt files individually using passkeys:
https://news.ycombinator.com/item?id=46895533
This give much more conscious control to the user knowing that they are explicitly encrypting which file with which passkey. Additionally, you can just download the page and serve it via localhost so that you always have control of the relying party for your passkey.
What an incredible article. More than its impressive documented scope and detail, I love it foremost for conveying what the zeitgeist felt at each point in history. This human element is something usually only passed on by oral tradition and very difficult to capture in cold, academic settings.
It’s fashionable to dunk on “how did all this cloud cruft become the norm”, but seeing a continuous line in history of how circumstance developed upon one another, where each link is individually the most rational decision at their given context, makes them an understandable misfortune of human history.
I wonder if you can hack a LocalStorage sync feature via ATProto PDS, since you can put arbitrary JSON records via /xrpc/com.atproto.repo.putRecord and not just Bluesky posts.
The only drawback I can think of is that all of your commits are broadcast on a megaphone to the network firehose, but encryption can alleviate that somewhat.
If you make it for yourself and no one else likes it, it is of value to you still.
If you make it for others but no one else likes it, it is of value to nobody at all.