I would like to give an update on "federation" on Bluesky.

[mcc@mastodon.social]

@erincandescent @ikuturso @trwnh @jrose I am proposing engineering a situation where did:plc:eepire and did:kad:eepire point to the same resource.

[trwnh@mastodon.social]

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

[fleeky@prsm.space]

@mcc nothing is stopping blue sky from blocking the other two instances right ? Also is it not the case that black sky has an incomplete view of the entire atmosphere like only a few days so it's still dependent on blue sky due to the high cost of infra for being able to contain that entire view ?

[trwnh@mastodon.social]

@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

[mcc@mastodon.social]

@fleeky 1. Correct
2. I don't know

[mcc@mastodon.social]

@trwnh @erincandescent @ikuturso @jrose I am proposing inventing a did:kad, or a did:kad2 if did:kad is already being used, and giving it whatever properties would be needed to make it work the way I said.

And yes, I'm proposing creating an exact clone of plc that doesn't depend on plc.directory.

[trwnh@mastodon.social]

@mcc @erincandescent @ikuturso @jrose right now the practical consideration for migration is one of the following:

- you have a did:plc and want to migrate to did:web
- you have a did:web and want to migrate to another did:web
- you have a did:web and want to migrate to did:plc

none of the three are currently possible, you will lose all your follow relations etc even if you replicate the exact same content or serve the exact same data repo

[trwnh@mastodon.social]

@mcc @erincandescent @ikuturso @jrose i think this effectively amounts to "just use a dht that everyone agrees on"

[mcc@mastodon.social]

@trwnh yes, that's why in my example I picked the first three letters of "kademlia"

[trwnh@mastodon.social]

@mcc ah, i missed that part ^^;

[erincandescent@akko.erincandescent.net]

@trwnh @mcc @ikuturso @jrose In did:plc:foo, foo is a base32(sha256(creation_request))[0:20] so its a 120-bit hash. I’m not confident of that’s long term security

Also the did:plc update metadata protocol is fundamentally dependent upon the existence of a central trusted system so you can’t just easily replicate it as a DHT system

[esoteric_programmer@social.stealthy.club]

@trwnh @lrhodes @mat @mcc @alter_kaker I thought @user.domain.tld is 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@mastodon.social]

@erincandescent @ikuturso @mcc @jrose i think you could replace it with signed updates but in doing so, you've basically just wrapped around to needing a pki

[erincandescent@akko.erincandescent.net]

@trwnh @ikuturso @jrose @mcc there are broadly 3 types of DID that exist at the moment:

1. Fixed unchangable keys (did:key)
2. Depend upon central system for updates (did:web, did:plc); did:web is decentralised in the sense anyone can run a server for said DIDs but a given DID is always tied to a given DNS domain
3. Dependent upon a blockchain for updates (most of them)

[mcc@mastodon.social]

@trwnh @erincandescent @ikuturso @jrose this raises an important question. Why the fuck are we not just using a pki to start with

[trwnh@mastodon.social]

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

[erincandescent@akko.erincandescent.net]

@mcc @trwnh @ikuturso @jrose did:plc is using a PKI but it also provides ways of doing account recovery that pure-PKI systems fail to acheive

[erincandescent@akko.erincandescent.net]

@mcc @ikuturso @jrose @trwnh basically it kind of comes down to average people are not great at handling cryptographic keys

[trwnh@mastodon.social]

@mcc @erincandescent @ikuturso @jrose uhhhh

"key management hard", basically

[mcc@mastodon.social]

@erincandescent i think in order to solve this problem without centralization you do need a ledger ("blockchain"). That's simply the way to get a canonically agreed on ordering of events. I think there are some reasons to go with a data structure *other* than literal blockchain for your ledger. But if you create a canonically agreed on ordering of events (which as far as I'm concerned you need if you want to support key rotation/did changes) then more or less by definition you've made a ledger