Skip to main content
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
DID Resolution PLC DIDs are resolved to a DID document (JSON) by making simple HTTP GET request to the PLC server. The resolution endpoint is: https://plc.directory/:did The PLC-specific state data (based on the most recent operation) can be fetched as a JSON object at: https://plc.directory/:did/data

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 method
GitHub
#bluesky #atprotocol #did
jonny
jonny  
•
i get that this is intended to be a "placeholder" DID method, but it tells the whole story of ATProtocol, no? "we didn't like the thing that already existed, so rather than attempting to make a bridge or backwards compatibility at all, we just made our own completely new mutually incompatible thing that serves exactly our purposes and no other."

Their reasons for not doing interop with AP are laughable: you could easily support messaging to/from AP servers from a new protocol.
Why not use ActivityPub?# ActivityPub is a federated social networking technology popularized by Mastodon. Account portability is the major reason why we chose to build a separate protocol. We consider portability to be crucial because it protects users from sudden bans, server shutdowns, and policy disagreements. Our solution for portability requires both signed data repositories and DIDs, neither of which are easy to retrofit into ActivityPub. The migration tools for ActivityPub are comparatively limited; they require the original server to provide a redirect and cannot migrate the user's previous data. Other smaller differences include: a different viewpoint about how schemas should be handled, a preference for domain usernames over AP’s double-@ email usernames, and the goal of having large scale search and discovery (rather than the hashtag style of discovery that ActivityPub favors).
jonny
jonny  
•
#Bluesky / #ATProtocol is an extremely funny protocol that is explicitly designed to ensure that there are still powerful entities that own your attention. Sure! you can host your own personal data store, but everyone else will be getting your posts through a Big Graph Service that necessarily crawl all posts on the network, so it's actually mostly irrelevant.

https://blueskyweb.xyz/blog/5-5-2023-federation-architecture
Network diagram showing data flow in the bluesky network. Individual users interact with personal data stores (PDS). Those PDS are crawled by Big Graph Services (BGS). BGS then feeds posts to AppViews and other feed generation services. Those feed generation services feed other posts back to your personal data store.

Federation Architecture Overview

Soon, we’re launching a sandbox environment for federation. In advance, we want to share some technical details about our design decisions.
blueskyweb.xyz
#bluesky #atprotocol
⇧