I would like to give an update on "federation" on Bluesky
Fediverso
328
Posts
104
Posters
587
Views
-
@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.
-
If you sign up with https://blacksky.community you get:
- Blacksky's "appview"/web frontend
- Optionally, Blacksky's PDS
- Blacksky's moderation layer (and you can optionally enable Bluesky's too)Almost-complete independence! What I'm not clear on is to whether, or to what degree Blacksky relies on Bluesky's "relay":
@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 ?
-
@erincandescent @ikuturso @trwnh @jrose I am proposing engineering a situation where did:plc:eepire and did:kad:eepire point to the same resource.
@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 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 ?
@fleeky 1. Correct
2. I don't know -
@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
@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.
-
@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 @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:plcnone 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 @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.
@mcc @erincandescent @ikuturso @jrose i think this effectively amounts to "just use a dht that everyone agrees on"
-
@mcc @erincandescent @ikuturso @jrose i think this effectively amounts to "just use a dht that everyone agrees on"
@trwnh yes, that's why in my example I picked the first three letters of "kademlia"
-
@trwnh yes, that's why in my example I picked the first three letters of "kademlia"
@mcc ah, i missed that part ^^;
-
@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? -
@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 @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
@mcc @erincandescent @ikuturso @jrose uhhhh
"key management hard", basically
-
@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
-
@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.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@mcc sad stuff 😢 Thanks for the history lesson and analysis.
-
@mcc Yeah. I don't see how that's sustainable. I'm not sure it's even sustainable for Bluesky.
-
@lrhodes Depends on how you do it I imagine. But remember that's several terabytes for the like what, three years or something Bluesky has been running. We will expect it to grow endlessly, and we should expect the growth to grow endlessly as Bluesky becomes more popular.
-
@mcc What's the monthly cost on maintaining several terabytes of data in perpetuity?
-
@game sì, ci sono anche soluzioni (purtroppo non previste da Mastodon) in cui alcuni utenti (i minori) accedono solo alle risorse locali o a un bouquet selezionato di istanze esterne, mentre altri possono utilizzare la federazione. Ma non sono di facile implementazione
@mapto @informapirata
-
t yet
-
@mcc I read your thread only now, and I wanted to thank you for posting all that. I am no fan of Bluesky and their one-instance federation, but I have a phony account there, to follow how it's going for them. Threads like yours fill in additional context. 🙏
-
Bonjour ! @Neko0001
