lmao taking a look at #ATProtocol / #Bluesky's implementation of #DID, and I think they missed the "decentralized" part in their "placeholder" DID method.
Your domain's DNS entries just contain a (truncated) hash that then has to be resolved at plc.directory
recall that the DID method (plc) is part of the DID, so a different method (eg. web) is a different DID. to switch, you'd need to set an alsoKnownAs entry. plc only supports AT handles for alsoKnownAs.
https://github.com/bluesky-social/did-method-plc#did-resolution
Your domain's DNS entries just contain a (truncated) hash that then has to be resolved at plc.directory
recall that the DID method (plc) is part of the DID, so a different method (eg. web) is a different DID. to switch, you'd need to set an alsoKnownAs entry. plc only supports AT handles for alsoKnownAs.
https://github.com/bluesky-social/did-method-plc#did-resolution
GitHub - bluesky-social/did-method-plc: A cryptographic, strongly-consistent, and recoverable DID method
A cryptographic, strongly-consistent, and recoverable DID method - GitHub - bluesky-social/did-method-plc: A cryptographic, strongly-consistent, and recoverable DID methodGitHub
jonny
•Their reasons for not doing interop with AP are laughable: you could easily support messaging to/from AP servers from a new protocol.
jonny
•https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
Federation Architecture Overview
blueskyweb.xyz