@mat @lrhodes @mcc @alter_kaker @esoteric_programmer the pds/storage can change because the identity is a separate layer.
-
@mat @lrhodes @mcc @alter_kaker @esoteric_programmer the pds/storage can change because the identity is a separate layer. the authority is a DID (most likely did:plc but did:web is also supported). the DID document points to your current PDS. this allows the pds to change as long as the did stays the same.
example: you are did:plc:whatever, and your pds is shiitake.example, but you migrate your data from shiitake to puffball. the did document updates the service pointer: https://web.plc.directory/did/did:plc:ewvi7nxzyoun6zhxrhs64oiz
-
@mat @lrhodes @mcc @alter_kaker @esoteric_programmer the pds/storage can change because the identity is a separate layer. the authority is a DID (most likely did:plc but did:web is also supported). the DID document points to your current PDS. this allows the pds to change as long as the did stays the same.
example: you are did:plc:whatever, and your pds is shiitake.example, but you migrate your data from shiitake to puffball. the did document updates the service pointer: https://web.plc.directory/did/did:plc:ewvi7nxzyoun6zhxrhs64oiz
@mat @lrhodes @mcc @alter_kaker @esoteric_programmer it's kind of like updating dns records. the did:plc stuff is fully in control of bluesky pbllc of course, so it's equivalent to everyone having an id of https :// plc.directory / whatever which is itself equivalent to serving http redirects.
-
@mat @lrhodes @mcc @alter_kaker @esoteric_programmer the pds/storage can change because the identity is a separate layer. the authority is a DID (most likely did:plc but did:web is also supported). the DID document points to your current PDS. this allows the pds to change as long as the did stays the same.
example: you are did:plc:whatever, and your pds is shiitake.example, but you migrate your data from shiitake to puffball. the did document updates the service pointer: https://web.plc.directory/did/did:plc:ewvi7nxzyoun6zhxrhs64oiz
@trwnh @mat @mcc @alter_kaker @esoteric_programmer Yeah, my understanding a while back was that the canonical location is defined by reference to the DID address. The way, you can still have a canonical address even if the originating account shifts to a new address. That prevents the old PDS from retaining authority. But so much has changed since I firmed that understanding that I wasn't sure whether or not it had changed. (One would hope the procedures for determining canonicity wouldn't change.)
-
@trwnh @mat @mcc @alter_kaker @esoteric_programmer Yeah, my understanding a while back was that the canonical location is defined by reference to the DID address. The way, you can still have a canonical address even if the originating account shifts to a new address. That prevents the old PDS from retaining authority. But so much has changed since I firmed that understanding that I wasn't sure whether or not it had changed. (One would hope the procedures for determining canonicity wouldn't change.)
@lrhodes @mat @mcc @alter_kaker @esoteric_programmer """fun""" fact btw: canonicity of at:// uri is different depending on whether you use the did or dns as the authority. so at://atproto.com has different properties than at://did:plc:ewvi7nxzyoun6zhxrhs64oiz -- the former will break if the dns handle ever changes, and the latter is supposed to be used whenever canonical references are needed. but guess which one gets exposed to user-facing stuff? that's right, did is backend, dns is frontend.
-
@lrhodes @mat @mcc @alter_kaker @esoteric_programmer """fun""" fact btw: canonicity of at:// uri is different depending on whether you use the did or dns as the authority. so at://atproto.com has different properties than at://did:plc:ewvi7nxzyoun6zhxrhs64oiz -- the former will break if the dns handle ever changes, and the latter is supposed to be used whenever canonical references are needed. but guess which one gets exposed to user-facing stuff? that's right, did is backend, dns is frontend.
@trwnh @lrhodes @mat @mcc @alter_kaker I thought
@user.domain.tldis just a way to point to@did:plc:blahblahblah, the same way we do with webfinger over here. Wouldn't this difference in the protocol make an impersonation attack more possible? -
@trwnh @lrhodes @mat @mcc @alter_kaker I thought
@user.domain.tldis just a way to point to@did:plc:blahblahblah, the same way we do with webfinger over here. Wouldn't this difference in the protocol make an impersonation attack more possible?@esoteric_programmer @lrhodes @mat @mcc @alter_kaker you are *supposed* to "convert" the user.domain.tld to did:plc:blah, but you can still construct references against user.domain.tld. but you're not supposed to. but every user-facing component only shows you the user.domain.tld instead of the did:plc:blah, so if you're just copying from your address bar, you are going to get the "wrong" identifier most likely.
it has the exact same properties as letting a dns name lapse and get reassigned.
