Post
1/
One of the places where many are hoping Bluesky and the ATmosphere improves is — DID-PLC.
DID-PLC and the centralized server https://plc.directory are at the core of what identity on Bluesky and the ATmosphere is based on.
Unfortunately it is centralized — which is a problem if you are trying to build a decentralized social-networking platform.
...
2/
Many have hoped that Bluesky decentralizes DID-PLC & https://plc.directory , or replace it with something decentralized.
And, I do think the Bluesky founders want to fix this — "plc" is short for "placeholder" after all.
But, it isn't decentralized yet.
Interestingly...
@reiver correction PLC was short for Placeholder, and that was changed to Public Ledger of Credentials last year.
It's being moved to a Swiss Association, and I think the implication is that it wouldn't just be Bluesky involved in it but also other companies.
The IETF working group charter also explicitly allows other DID methods and identity methods to be supported (criteria tbd).
https://plc.directory is currently centralized, yes, but there's a lot of work underway to make it able to be replicated (changes announced just last week), so if need be it would be possible to fork the ledger.
did:web is also supported, but doesn't have a full history identity chain and has some portability issues. Other methods for the future might be did:webvh, did:plcbft, etc.
did:webvh has similar properties to did:plc whilst being decentralized by domain names, which may be more unstable than a centralized service.
A new endpoint is being looked at to allow publish signed identity events, which can prove if the directory ever refused to accept data.
3/
Interestingly, the Fediverse already has a decentralized equivalent to https://plc.directory .
On the Fediverse it is where a Fediverse ID:
＠joeblow＠example·com
Is resolved using WebFinger:
https;//example·com/.well-known/webfinger?resource=acct:joeblow＠example·com
Which points you to the activity page:
https;//example·com/users/joeblow
Which returns the activity actor JSON-LD.
(BTW, plc.directory also returns JSON-LD)
@reiver funnily enough, knowing the trade-offs and implications of different systems, I actually find myself preferring did:plc, explicitly because it doesn't depend on having control of a domain name. It allows portability of identities in a way where only one domain need be retained, not N domains.
Webfinger also conflates your identity with your handle, and these are explicitly separate concepts in AT Protocol.
@reiver webfinger and did:web are arguably very similar. Both tie your identity to a domain name, whether under your control or not.
@reiver Out of curiosity ... could I use this system _today_ to make my handle say @felicitas@pojtinger.com as a Mastodon user? Assuming I have control over the web server running at https://felicitas.pojtinger.com/?
You would have to control the web-server running at pojtinger.com
When the Fediverse sees the Fediverse ID:
＠felicitas＠pojtinger·com
It will try to do a WebFinger look up on pojtinger.com
That WebFinger service could redirect the request to felicitas.pojtinger.com or another other place.
And then you could have Mastodon running on another domain
@reiver Oh, that's super neat! As long as I can do said Webfinger setup via a serverless function that would be easy enough to setup. Would both the @pojntfx and @felicitas@pojtinger.com handles keep working? Or would latter "resolve" in the client and just redirect to the mastodon.social domain as a HTTP redirect would?
Ah. You want to point @felicitas@pojtinger.com to your mastodon.social account.
From a protocol perspective you could do it, but — I think you would have to configure mastodon.social to include your acct-uri in the WebFinger response — acct:felicitas@pojtinger.com.
The mastodon.social sysops probably won't let you do that 🙂
Although it would be cool if the did it in the future
