I would like to give an update on "federation" on Bluesky.
-
@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
-
@eniko I think M Kasprzak actually has a fork of the official Bluesky PDS, right now, that also publishes to ActivityPub. I think Wafrn can do that too. So that would be an example of "bridging" like I mean— you could start syndicating your bluesky posts to Fediverse, and if you ever bug out from Bluesky just disconnect those endpoints and now you've just got a fediverse server. But this scenario assumes you weren't already more established and comfortable on Fediverse than Bluesky to start with
@mcc yeah I've been asked repeatedly to join wafrn but I've never wanted to because I don't want to post the exact same things on bluesky that I do here. They're two different cultures that react very differently to posts. And also, now, it's been made clear to me it's not necessarily safe to post as freely on bluesky
-
@mcc yeah I've been asked repeatedly to join wafrn but I've never wanted to because I don't want to post the exact same things on bluesky that I do here. They're two different cultures that react very differently to posts. And also, now, it's been made clear to me it's not necessarily safe to post as freely on bluesky
@eniko Yes, I think these are great points.
-
-
@eniko In a world where Mastodon/ActivityPub doesn't exist, having the PDS would be a cool opportunity because if you ever do bug out from bluesky, instead of having to find someone replicating that giant teetering ATProto stack you could bridge to, or create, some kind of alternative system. But in this actual world this feels pointless since the alternative systems (like ActivityPub) that exist already are more capable to begin with, so why not just make the posts there to begin with.
@mcc yeah i think the best case i can make is that if you don't like the people currently on the fediverse but do like the people currently on bluesky, then minimizing the risk of using bluesky might be a smart middle ground. (you could always run an isolated mastodon server, but you could also just run phpbb or an irc server or whatever at that point.)
-
@nullpotential @mcc people on Bluesky who have soured on fedi often complain about having been lectured about using alt text and CWs for what it's worth.
@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.
-
@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.
-
@erincandescent @ikuturso @trwnh @jrose I am proposing engineering a situation where did:plc:eepire and did:kad:eepire point to the same resource.
-
@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":
(EDIT 2: There was an edit here with corrections, but I've removed that because the corrections may have been less correct than the original.)
@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 ^^;
-
@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
