I would like to give an update on "federation" on Bluesky.
-
@trwnh yes, that's why in my example I picked the first three letters of "kademlia"
@mcc ah, i missed that part ^^;
-
@mcc @erincandescent @ikuturso @jrose i think this effectively amounts to "just use a dht that everyone agrees on"
@trwnh @mcc @ikuturso @jrose In
did:plc:foo, foo is abase32(sha256(creation_request))[0:20]so its a 120-bit hash. I’m not confident of that’s long term securityAlso the
did:plcupdate 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 -
@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 @mcc @ikuturso @jrose In
did:plc:foo, foo is abase32(sha256(creation_request))[0:20]so its a 120-bit hash. I’m not confident of that’s long term securityAlso the
did:plcupdate 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@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
-
@trwnh @mcc @ikuturso @jrose In
did:plc:foo, foo is abase32(sha256(creation_request))[0:20]so its a 120-bit hash. I’m not confident of that’s long term securityAlso the
did:plcupdate 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@trwnh @ikuturso @jrose @mcc there are broadly 3 types of DID that exist at the moment:
- Fixed unchangable keys (
did:key) - Depend upon central system for updates (
did:web,did:plc);did:webis decentralised in the sense anyone can run a server for said DIDs but a given DID is always tied to a given DNS domain - Dependent upon a blockchain for updates (most of them)
- Fixed unchangable keys (
-
@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
@trwnh @erincandescent @ikuturso @jrose this raises an important question. Why the fuck are we not just using a pki to start with
-
@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.
-
@trwnh @erincandescent @ikuturso @jrose this raises an important question. Why the fuck are we not just using a pki to start with
-
-
@trwnh @erincandescent @ikuturso @jrose this raises an important question. Why the fuck are we not just using a pki to start with
@mcc @erincandescent @ikuturso @jrose uhhhh
"key management hard", basically
-
@trwnh @ikuturso @jrose @mcc there are broadly 3 types of DID that exist at the moment:
- Fixed unchangable keys (
did:key) - Depend upon central system for updates (
did:web,did:plc);did:webis decentralised in the sense anyone can run a server for said DIDs but a given DID is always tied to a given DNS domain - Dependent upon a blockchain for updates (most of them)
@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
- Fixed unchangable keys (
-
@erincandescent @ikuturso @mcc @jrose isn't plc basically custodial keys?
-
@mcc @erincandescent @ikuturso @jrose uhhhh
"key management hard", basically
-
@erincandescent @ikuturso @mcc @jrose isn't plc basically custodial keys?
-
@erincandescent I have an entirely workable proposal for how to achieve that in a distributed system, which the mastodon dot social post length is too small to contain
-
@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.
@trwnh @lrhodes @mat @mcc @alter_kaker This is offtopic in a way, but oho, I didn't have to look too deeply to find this:
https://github.com/qwell/bsky-exploits
nothing extremely serious, but could be used for fishing campaigns and the like pretty easily -
@erincandescent I have an entirely workable proposal for how to achieve that in a distributed system, which the mastodon dot social post length is too small to contain
@mcc @erincandescent we should sync up about that at some point, we've thought about it also and it'd be a shame to never turn it into a spec
-
@mcc @erincandescent we should sync up about that at some point, we've thought about it also and it'd be a shame to never turn it into a spec
@mcc @erincandescent the historical answer to why atproto isn't using traditional PKI, as far as we can tell, is that the authors were under the impression DID is a lot more useful than it is. just a guess on our part.
-
@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
@mcc@mastodon.social @erincandescent@erincandescent.net are you claiming that 90s pattern of long term identity keys that sign use keys and can invalidate themselves by signing a new identity key is blockchain?
(i mean sure, there's a chain of keys, but no blocks required)
-
@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
@trwnh
No, the bittorrent DHT has methods to update content sent in the DHT with no need for a PKI: https://bittorrent.org/beps/bep_0049.html
@erincandescent @ikuturso @mcc @jrose