Piero Bosio Social Web Site Personale

@mcc @erincandescent @ikuturso @jrose this would depend entirely on how did:plc and did:kad are defined as did methods. the "eepire" part of plc is cryptographically generated from the did creation request: https://web.plc.directory/spec/v0.1/did-plc

you sign the operation then hash it then truncate to first 24 characters

thus any did method that generates the same 24 character id is just an exact clone of plc

@erincandescent @ikuturso @mcc @jrose yep, did:plc is equivalent to did:web:plc.directory (which is equivalent to https://plc.directory)

it's basically dns all over again, but in a different format (did documents instead of resource records). plc.directory is basically the authoritative nameserver.

@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.

@ikuturso @nullpotential @mcc signing up for mastodon.social is not the worst thing you could do. setting up your own server and being subject to harassment by widely blocked servers you didn't know existed? the immediate response was to look for shared blocklists, but that just led to more conflict because again, how are you supposed to be aware of the years-long social dynamics of a space you literally just joined? the common refrain of "just use a different instance" was taken dismissively.

@ikuturso @jrose @mcc yeah, unfortunately bluesky has zero interest in supporting did migrations. they only support changing your dns handle

EDIT: source https://bsky.app/profile/bnewbold.net/post/3lchpwc2hws2r

@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

@ikuturso @esoteric_programmer @alter_kaker @mcc that $34/month is enough for 2 hours per the article

@carcosa @eniko @mcc pretty much. being on bluesky's pds means you are subject to their content takedowns. being on another pds means the content stays up but they can still censor it at the relay or appview.

@msh @ikuturso @mcc @swetland @gbargoud however, with that said, the vast majority of people are using the official apps. so the blocks and gates "work" in the sense that the vast majority of people are subject to them. but it remains trivially easy to just *not* respect those blocks and gates, because all the data is forever public

@msh @ikuturso @mcc @swetland @gbargoud arguably bluesky could address those needs better because they maintain control over the full vertical and can apply advisory policies that don't have any real security backing. you can use a different appview or just browse the data directly and *not* apply blocks, gates, etc... this horrifies most people who learn about it and horrifies them further that there's nothing they can do about it. all the policies only apply if you're using the official apps.

@gbargoud @mcc a fedi server could store *public* data in an atproto data repo but that doesn't get you much. wafrn implemented ap then atproto, at least for the app.bsky records and i guess they have to squeeze everything into 300 characters or less and only allow cross-publishing of public posts.

@julian @nutomic for example, some impls attach replies even if they do not share the same context, as a compatibility measure. that kind of stuff

@julian @nutomic i think it's unavoidable that at some point you will end up having to recognize that two context ids may be equivalent, perhaps with one of them being canonical. "cached representation of remote content" is fine and there isn't necessarily a problem there. it depends on how much you embrace the idea of each publisher being allowed to make their own claims (and how much you allow "clean up" after the fact)

@julian i am still kind of confused what this fep adds over 7888 which already describes ownership and inheritance. i guess upgrading some SHOULDs to MUSTs? which i don't think are actually MUSTs in practice... any missing info can be skipped over.