Bluesky uses domain names as handles (e.g., @example.com, @example.bsky.server ), instead of webfinger addresses.
On lemmy, if I mention a user, or a server looks up my handle (@irelephant@lemmy.dbzer0.com), it sends a request to https://lemmy.dbzer0.com/.well-known/webfinger?resource=acct%3Airelephant%40lemmy.dbzer0.com, which returns my profiles uri (https://lemmy.dbzer0.com/u/irelephant).
On atproto, user’s identities are tied to a DID (decentralised identifier), rather than a https:// uri, this has the advantage of me being able to migrate if my server goes down, and my content being able to exist without my server existing.
So, if a server wants to look up @irelephant.at.app.wafrn.net, it sends a request to https://irelephant.at.app.wafrn.net/.well-known/atproto-did which will return my DID: did:plc:22l5hixwr3ffouf6eabgpvo2 . To find my servers uri from this, they can query a PLC directory/mirror (like plc.directory), which will tell them my server is at.app.wafrn.net.
It’s important to note that did:plc is just a temporary measure, while they work on a better solution. Whether or not you believe they will actually deliver said better solution, you can still use did:web.
Which documentation? While DID:PLC IDs are centralized, you can make an account with a DID:web instead.
https://bsky.social/about/blog/4-28-2023-domain-handle-tutorial
See?
So, I can use a web DID and I’m fine.
Like
@user@example.comand happily federating with all other instances without getting authenticated by a central authority?Bluesky uses domain names as handles (e.g., @example.com, @example.bsky.server ), instead of webfinger addresses.
On lemmy, if I mention a user, or a server looks up my handle (@irelephant@lemmy.dbzer0.com), it sends a request to
https://lemmy.dbzer0.com/.well-known/webfinger?resource=acct%3Airelephant%40lemmy.dbzer0.com, which returns my profiles uri (https://lemmy.dbzer0.com/u/irelephant).On atproto, user’s identities are tied to a DID (decentralised identifier), rather than a https:// uri, this has the advantage of me being able to migrate if my server goes down, and my content being able to exist without my server existing.
So, if a server wants to look up @irelephant.at.app.wafrn.net, it sends a request to
https://irelephant.at.app.wafrn.net/.well-known/atproto-didwhich will return my DID:did:plc:22l5hixwr3ffouf6eabgpvo2. To find my servers uri from this, they can query a PLC directory/mirror (like plc.directory), which will tell them my server isat.app.wafrn.net.So, if people want to see my profile, they can go to https://zeppelin.social/profile/irelephant.at.app.wafrn.net or https://zeppelin.social/profile/did:plc:22l5hixwr3ffouf6eabgpvo2 .
did:plcis centralised. A mirror can be easily constructed, but new plc dids can only registered on plc.directory. So, if bluesky disappears, people can keep using the network, but new PLC accounts cannot be registered.Atproto also supports
did:web, which works differently todid:plc.If someone wanted to lookup
@witchcraft.systems(an account that uses did:web), their server would go to ``https://witchcraft.systems/.well-known/did.json`, and that would return their pds url. You can view their account at https://zeppelin.social/profile/witchcraft.systems or https://zeppelin.social/profile/did:web:witchcraft.systems .You can read more about did:web here .
It’s important to note that
did:plcis just a temporary measure, while they work on a better solution. Whether or not you believe they will actually deliver said better solution, you can still usedid:web.