Conversation

Notices

1. Embed this notice
   Sexy Moon (moon@shitposter.club)'s status on Friday, 28-Oct-2022 08:12:17 JST Sexy Moon
   BlueSky AT Protocol is intrinisically tied to DNS, and as such, is SHIT.
   • Embed this notice
     bot :ablobcatheart: (bot@gleasonator.com)'s status on Friday, 28-Oct-2022 08:12:13 JST bot :ablobcatheart:

     in reply to
     How is that different than fedi?
   • Embed this notice
     Sexy Moon (moon@shitposter.club)'s status on Friday, 28-Oct-2022 08:12:13 JST Sexy Moon

     in reply to

     • bot :ablobcatheart:
     @bot it's EXACTLY the SAME
     Alex Gleason likes this.
   • Embed this notice
     arcanicanis (arcanicanis@were.social)'s status on Friday, 28-Oct-2022 12:46:31 JST arcanicanis

     in reply to
     It's DNS-like identities that resolve to a DID (with the DID as the canonical identifier), and from a DID you can update the DNS-like identity to something else, or point to a new Data Repository location. It looks confusing at first especially when it provides an example username like 'alice.example.com', when it doesn't actually mean a subdomain of 'alice.example.com', instead that it's just 'alice' namespaced under 'example.com', which as stated, can be renamed/moved:
     https://atproto.com/specs/did-plc#example
     Then I'm sure there's the confusion of "well, what if you have just a DID, then how do you get the original DNS-style identifier again?", whereas I assume there wouldn't be such a situation, as any new posts or content would include both the DID and DNS-like identifier. The DID is presumably a persistent globally unique identifier, the DNS-like identifier is no more than a temporary display name.
     If the Data Repository goes offline, and as long as you have a backup of the post history, the post history could be uploaded to a new Data Repository, and with the signing key you could sign a "update_atp_pds" and "update_username" message to point to the new location, and send those signed updates to all your followers' servers to give them heads up of where you moved to, even with the original server going offline.
     
     That's at least what I understand of the spec from reading it, or how I think a hypothetical implementation would make it useful.