@ikuturso

...this is just a surface level commentary on what happened, but if you were BIPOC or followed prominent BIPOC folk here you could eventually see a pattern in the interactions.

I know Bluesky is definitely not a panacea in this regard either (otherwise why the tremendous effort out into blacksky?), but they did address the wants and needs of nonwhite people better at least initially, at the app level.

Anyways what I am seeing is that both ecosystems here are making similar mistakes and facing similar challenges, and it is to do with some aspects of insufficient diversity both technically and socially.

@mcc @swetland @gbargoud

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

@eniko @mcc If I understand correctly (and it is possible and likely that I don't), if you host your own PDS, you can use the rest of the stack from Bluesky, get banned, and migrate to Blacksky without losing your post history. And theoretically your social graph, though in practice Bluesky will be blocking almost everyone in it.

I've no interest in it either way, given that Bluesky is the toxic liberalism site in the same way that X the Everything App is the toxic reactionary site.

@esoteric_programmer @alter_kaker @mcc as I understand it the cost of a relay has gone down because you can run it without keeping full account of the message history for all time and instead restrict what you have to a time-window.

Raises the question of whether that's good enough if we want real alternatives to the official company infra though.

@jrose @mcc Even the portability being better is somewhat theoretical right now because if your identity is using did:plc then you are unable to move away from did:plc and Bluesky PBC has custody of your keys... And also like people have noticed hosting your own data in a PDS does not really make you independent from their actions so the point of doing it is somewhat unclear.

@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

@trwnh @ikuturso @jrose if someone develops a better did method, surely you could just have two DIDs point to the same repo? Use Good DID with non-bluesky systems and Bad DID with bluesky systems. Maybe they could even have the same "key" (the Z in did:Y:Z)

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

@mcc @trwnh @ikuturso @jrose But the problem is that did:plc by definition always points to Bluesky’s DID repo.

@mcc @trwnh @ikuturso @jrose But the problem is that did:plc by definition always points to Bluesky’s DID repo.

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

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

@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