Yes, you're right, although there was a lot of churn in SvelteKit when it was in beta--maybe they had that in mind. Of course, it was marked as a beta, so it's hard to blame them too much. But I was using Kit heavily during that period and ended up getting frustrated by the whiplash, and then the addition of runes (which was announced in late 2023 even if it wasn't released until 2024) was what made me lose interest in Svelte. I still have some fondness for the framework though.
They explicitly mention that Svelte hasn't changed much since version 3? Svelte 5 did introduce runes but, as you say, still kept legacy code compatible.
What about using Nostr relays to also back up your data passwords? I built a library called Tablinum around this idea. Local first but backed up to Nostr relays using NIP-59 gift wrapped events.
the only true centralized part is the did:plc registry and thats designed to be fully auditable. all canonical data is stored on your pds so if you self host that you get full control.
decentralization is not about the number of app instances but how easy it is to switch from one to another. on that metric bluesky is already better than fediverse.
That’s a very narrow definition of decentralisation. In any case - both atproto and fediverse are massively centralised compared to something like Nostr, and it’s not even close.
The fact that the PDS in practice owns your identity in the vast vast majority of cases is such a dumb trade off that it’s honestly laughable. Should Bluesky decide to splinter off of the network there would be like 50000 people left.
Stop telling people that it’s decentralised in any meaningful way and be honest about it instead. That’s the issue. The dishonesty and tricking users.
Nope. When I’m talking about identity I’m speaking strictly of the keys that sign your messages and the pub key derived from it. In every other cryptographic system that is your identity. It is absolutely correct that the PDS has complete control over your keys when it comes to 99.99% of users. I challenge you to prove the opposite.
> A set of data describing the DID subject, including mechanisms, such as cryptographic public keys, that the DID subject or a DID delegate can use to authenticate itself and prove its association with the DID.
One of those properties is the "verification method", which tells you what to do to verify the identity. So you just do whatever is in that, and that gives you the identity. In other words, the broadest part of the spec is very pluggable, it does not describe the answer to your question in all cases.
So let's get more specific: One kind of DID, and the one that's used by virtually all of atproto users, is DID:PLC. As you can see from my DID above, I'm using the PLC method for my DID.
(Note that, before we get into any other part of it, this document points at my PDS, https://morel.us-east.host.bsky.network . So already, without going further, this is why your original comment is wrong: my identity points at my PDS, my PDS does not point at my identity.)
This specifies what goes into the "verification method" of a DID document that uses this method. In this case, if you look at mine, you'll see that it points (eventually) to https://www.w3.org/TR/cid-1.0/, which is what the Multikey stuff is about. From that spec:
> Controlled identifier documents identify a subject and provide verification methods that express public cryptographic material, such as public keys, for verifying proofs created on behalf of the subject for specific purposes, such as authentication, attestation, key agreement (for encryption), and capability invocation and delegation. Controlled identifier documents also list service endpoints related to an identifier; for example, from which to request additional information for verification.
This is already getting deep in the weeds, but the point is that the publicKeyMultibase is the encoded form of the public key that controls my identity. So that's where that lives. What about its associated private key? Well, it can be anywhere! From an identity perspective, the location of the private key doesn't matter. Only that whoever has that key produces information under that identity, when signed.
So let's talk in practice: when you sign up for Bluesky, they store the private key for you. This way, for users that don't care about any of these details, they do not have to think about it at all. It's saved with the rest of your account data, you don't have to worry about backups or anything.
However, at any time, any user can register a rotation key with the PLC directory. To do this, you generate a new public and private key, and then store that private key wherever you'd like. All the usual caveats here apply. You can then use your existing private key to add this new public key to your account. Once you do that, it shows up in your DID document as a rotation key. You can use that rotation key to add more keys, remove the Bluesky owned keypair, whatever you want. Now it's not stored by Bluesky.
The majority of users have not done this, it's true. But they can. Whenever they'd like.
That's a lot of information about something that does not really matter in practice. It's not until ew get to the very end of your comment that we get to the actually relevant part for the discussion.
> So let's talk in practice: when you sign up for Bluesky, they store the private key for you. This way, for users that don't care about any of these details, they do not have to think about it at all. It's saved with the rest of your account data, you don't have to worry about backups or anything.
> However, at any time, any user can register a rotation key with the PLC directory. To do this, you generate a new public and private key, and then store that private key wherever you'd like. All the usual caveats here apply. You can then use your existing private key to add this new public key to your account. Once you do that, it shows up in your DID document as a rotation key. You can use that rotation key to add more keys, remove the Bluesky owned keypair, whatever you want. Now it's not stored by Bluesky.
> The majority of users have not done this, it's true. But they can. Whenever they'd like.
The Bluesky PDS stores (and has access to!) your private keys. They are in full control of your identity. It just so happens that 99.99% of users are on the Bluesky PDSs AND 99.99% of users will choose the path of least resistance and in practice NEVER register an external rotation key. This is exactly the problem. It is massively centralized and a rug pull from Bluesky would effectively just kill off the network.
It's insane that this is just hand-waved away because "you can just self-host" or "you can just register an external rotation key". If you think users will actually do this I have a bridge to sell you.
2. People who would try to figure exactly how decentralized something is.
If you are the latter, you would instantly question the data model of Bluesky and of Mastodon as well. If you are the former then that just sounds like a buzzword.
The end of the article explains why this isn’t necessarily better than a centralised service. Yes - you can self host but no one (yes, there a few exceptions) does in practice. Your PDS host can pretend to be you on any atproto application.
How the addition of user choice doesn't make it better. I agree it's suboptimal, but I feel its still a clear improvement over centralized services. Getting to choose who, if anyone, I trust as my provider is better than having no choice.
Well it's a very well understood concept in cryptocurrency – you just keep your seed phrase somewhere like on a paper wallet. And if you're less paranoid then millions of people use some thing like MetaMask which there could be an equivalent of for identity management relevant to atProto– or maybe there is?
Atproto is not decentralised, it’s faux decentralised. You can technically be sovereign, but incentives and the way things have been done results in massive centralisation - 99.9% of users are on a Bluesky PDS and have not registered a higher priority rotation key. And they won’t, ever, because that’s how humans work.
The day Bluesky decides to enshittify there’s a very real possibility that they might also just stop allowing people to extract their keys and splinter off the network. The enshitification begins when VCs turn upp the heat it they start getting low on cash.
ATP is more decentralized than X at least. Decentralized as a term is almost as loaded as Democratic. :)
Anyway I think we can agree on enshitification is coming soon. I'm just looking for signs of that's actually happening (or a counter theory that it would not happen)
The easy way is to create an account on Bluesky. That's as simple as creating an account on any other social network. The important bit though is that you can then, if you want, migrate to a different host and take your identity with you, or if you're brave you can self-host. This is by its nature something for power users, but regular users can use Bluesky accounts without ever knowing or caring about PDSs, DIDs or signing keys etc.
“The signing key is entrusted to the PDS so that it can manage the user's data, but rotation keys can be controlled by the user, e.g. as a paper key. This makes it possible for the user to update their account to a new PDS without the original host's help.”
Yes you can but the vast majority don’t, and that is what matters. When Bluesky goes rogue because of profitability issues or VC pressure, the vast vast majority of users lose their identities on the wider network. Users will choose the path of least resistance. It’s all about incentives.
