But what about the DIDs, the things used to actually identify accounts within the ATproto ecosystem:
But Bluesky has developed its own DID method, did:plc. Today, did:plc stands for “Public Ledger of Credentials”, however it originally stood for “Placeholder DIDs”, with the hope of replacing them with something else later. The way that did:plc works is that Bluesky hosts a web service from which one can register, retrieve, and rotate keys (and other associated DID document information). However, this ledger is centrally controlled by Bluesky.
It’s literally not possible to have a functional PDS without registering with a Bluesky server and they maintain indefinite control over the ledger. All your data is tied to this DID, it’s how the entire protocol is designed to identify stuff, how decentralised is your data if it’s dependent on Blusky (the company) assigning you an identity?
After reading the article i think you might be wrong with this one.
From what i got now is that there are 3 layers
First is storage which can be completly or is decentralised
Then backend/server/application layer which can be bsky or whatever ticktok alternative gets made which is not decentralised
and then user layer/view which depends on the application
What i want to say is that the relay can be exchanged through something else and then entirely including moderation and all
So pro atProto is:
And pro ActivityPub is:
pro ActivityPub? (unsure about the technical details)
But what about the DIDs, the things used to actually identify accounts within the ATproto ecosystem:
It’s literally not possible to have a functional PDS without registering with a Bluesky server and they maintain indefinite control over the ledger. All your data is tied to this DID, it’s how the entire protocol is designed to identify stuff, how decentralised is your data if it’s dependent on Blusky (the company) assigning you an identity?
i forgot the DIDs
Oh no