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

[boris@cosocial.ca]

@mcc for illegal content (what is described as network abuse & infra moderation here https://docs.bsky.app/blog/blueskys-moderation-architecture) they likely take down the entire account

Yes Bsky _could_ delete posts by like … accessing the blob directory or deleting/editing SQLlite on disk but that’s tinkering. There’s no like masquerade as Boris function to do this in any sort of consolidated way across accounts.

Just like Google _could_ delete something in GDrive.

[mcc@mastodon.social]

@KnightMustard No. I am saying a different group of people got harassed, a few years back, and I saw people leave the Fediverse as a result. My perception, which obviously is the perception of an outsider and so not trustworthy, is that black Fedi is smaller now than it used to be.

Rudy says he's never used Fedi.

[evan@cosocial.ca]

@mcc thanks for this!

[mastodonmigration@mastodon.online]

@ikuturso @benroyce @txtechnician @mcc

How much has actually been invested in Bluesky? Public information (https://accessipos.com/bluesky-stock-ipo/) is three rounds, a seed round and an $8M in 2023 and $15M (Blockchain Capital) in 2024. In January 2025 a round lead by Bain Capital (https://www.businessinsider.com/x-competitor-bluesky-valuation-new-funding-round-2025-1) was reported setting valuation at $700M, but no further info if that round closed has been reported. Is the total to date $23M plus seed accurate? What happened with the big January Bain Capital round?

1/

[benroyce@mastodon.social]

@mastodonmigration @ikuturso @txtechnician @mcc

good question

we can calibrate with earnings (what, about $0?), the length of time, and the nature of the lenders, and arrive at a nice measure of how close bluesky is to plutocrat destruction

[fontenot@mastodon.social]

@mcc @aeva @cthos

This is just me thinking out loud without much direct knowledge, but isn't live Atmosphere content supposed to remain available on its home PDS indefinitely? So couldn't an AppView implement an LRU cache rather than a full mirror of all content? Or does this storage cost come from something else that can't be trivially re-fetched later?

[mcc@mastodon.social]

@fontenot @aeva @cthos One of the expected features of an AppView is full text search. This is a primary product differentiator versus Mastodon and users will be surprised if it is absent.

[txtechnician@mastodon.social]

@mastodonmigration @ikuturso @benroyce @mcc Wait!

I got it. What if we got the government to fund it! /s

[benroyce@mastodon.social]

@txtechnician @mastodonmigration @ikuturso @mcc

uggh

[fontenot@mastodon.social]

@erincandescent @ikuturso @mcc @trwnh @jrose

It's vulnerable to collisions, but I don't think those get you much with PLC? (Only the author of a DID creation request could create the collision.)

For pre-image, it inherits the security properties of SHA-256, which is probably fine, unless you're willing to brute-force the full 120 bits, which is well out of range of foreseeable technology I think - the whole Bitcoin network does like 2^96 hashes of SHA-256 per *year*.

[fontenot@mastodon.social]

@mcc @aeva @cthos

That's a great point, and I'm guessing that what @cthos meant by "lightweight" AppView was precisely that it doesn't indefinitely store media - it either has a LRU cache or relies on the Bluesky PBC network's CDN.

[cthos@mastodon.cthos.dev]

@fontenot @mcc @aeva whatever this thing is doing: https://github.com/alnkesq/AppViewLite

(I have not investigated past their readme)

[fontenot@mastodon.social]

@cthos @mcc @aeva

Thanks! Yes, it looks like the 2 GB / day estimate was from early January, and they didn't implement the ability to cache images until February, so that's *just* for posts, replies, likes, etc, not a full mirror of the network.

(And in fact the image caching ability is on-demand, they don't get fetched from the PDS until someone using the AppView actually tries to view them. The software can also use the PBC's CDN.)

[artha@mastodon.art]

@mnordhoff The DID concept is so strange to me, because they did already figure out they could use DNS for this…? So why bother?

[cypherhippie@chaos.social]

@mcc what about the PLC DID directory?

AFAIK:

1) ‘blacksky community’ doesn’t have control over ‘their accounts’ as long as they don’t run their own directory.

2) running an ‘independent directory’ means: no zerocost migration between networks and no coherent communication between networks without bridging elements.

I find it distressing that, as of now, most bsky documentation still omits the fact that the directory underpins *everything*.

Paul Fuxjäger (@cypherhippie.bsky.social)

Looks like the component that carries ALL the weight of ‘credible exit’ marketing claims is exposed to increasing levels of spam/dos. *absolutely nobody* saw that coming. /SCNR Longterm viable ‘DID:PLC Registry Write Access Governance Model’, anyone? [contains quote post or other embedded content]

Bluesky Social (bsky.app)

[mcc@mastodon.social]

@cypherhippie PLC is bullshit and honestly, I believe it is not possible to work around it. Or rather I have an entire design proposal for how to fix plc (replace it) and I know at least one other person with a design proposal for how to fix it (by replacing it), but I don't know how to solve the social part because the social part is "convince bluesky to give up power" and I can't think of a reason they'd do that.

[cypherhippie@chaos.social]

@mcc interesting, you are suggesting another DID method or something completely different?

[zedthered@mastodon.social]

@mcc I'd love to migrate but it's all and I mean ALL way over my head

[mnordhoff@infosec.exchange]

@mcc 4 days later Bluesky has announced an intention to establish an independent Swiss entity to manage the DID database. So there's that!

Creating an Independent Public Ledger of Credentials (PLC) Directory Organization | Bluesky

The Bluesky Social app is built on an open network protocol that refers to each user by a unique Decentralized Identifier, or DID (a W3C standard). The most popular supported DID method was developed in-house by Bluesky Social, and is called "Public Ledger of Credentials", or PLC. The PLC identity system currently relies on a global directory service to distribute identity updates, and that directory service has been operated by Bluesky as well.

(docs.bsky.app)

It hasn't happened yet, and it remains to be seen how it will be funded, whether it will have real independence, etc., but still?!

[mwkair@infosec.exchange]

@dalias @erincandescent @mcc Do you have a more detailed write up somewhere I can read? If it’s impossible to sell identities, isn’t it also impossible for me to prove that I successfully regained control of my account after a potential compromise (which is effectively a transfer)?

More importantly, what if I initially signed up using an easy hosted service. Let's say it's managed by Bluesky PBC. A few months later, I become more knowledgeable and decide to manage my own keys. Unfortunately, I have no way to prove that Bluesky PBC actually transferred my account to me. They could have secret unpublished recovery policies just like any potential seller could. Call me an idiot for ever trusting them, but now I have to start over with a new account just because I was ignorant about key management (average person) when I first created it.

Even if I manage my own keys from the start, if I ever decide my device may have been compromised at the time of creation, my account is useless because an attacker may have created a secret policy before I created one of my own. In this case, I'm effectively an account buyer, and the attacker can steal it "back" from me whenever.

I'm not remotely knowledgeable about this subject, but it seems to me that an important (the important?) part of a rotation mechanism is that I can move forward with peace of mind no matter how much I screwed up security in the past. Correct me if I'm wrong.

I think the above is better explained, but I also tried to make up two scenarios in case I was unclear.

Scenario 1:

1. I have reason to suspect that all my secrets have been exposed. Out of caution, my assumption is full compromise including keys and any unpublished earlier-notarized records I may have stashed. (If I could keep the pre-notarized records secure, I could just as well have kept a special recovery key secure). No worries, though. This is why we’ve built a rotation mechanism

2. The idea here is that I will rotate keys before the attacker does anything and go on my merry way confident in my security. Let’s say I succeed at this. I have new keys, and several years pass.

3. Unbeknownst to me, the attacker actually got there first before I completed step 2. Several years later, they publish their secret earlier notarized rotation. Suddenly and unexpectedly, I lose the account I spent several years confidently using.

It seems like preventing ownership transfer necessarily means I can’t prove that I’ve regained control over my own account (which is sort of a transfer back to me). I need some way to lock out someone who I assume may have stolen all my secrets. If I can do that, what stops me from transferring control of my account to a buyer? (See below for a scenario where an attack forces me to give up my ability to steal back control, but I still can't prove it to a potential buyer)

Or is the idea is that the recovery policy would specify that the "earliest *published* rotation" wins rather than the "earliest *notarized* rotation"? But doesn't that kinda violate the no-ledger goal?

Scenario 2:

1. I create an account. I create two recovery policies, both of which specify the "earliest published" policy for future key rotations. I keep the earlier-notarized one private because I want to be able to fraudulently sell my account and steal it back.

2. An attacker steals all my secrets and notarizes a rotation. They use the private, earliest-notarized policy. At this point, they don't publish.

3. I rotate my keys. Since the attacker may have both policies, I'm forced to publish and exercise the earliest policy in my possession.

4. The attacker tries to steal my account. By notarization date, they would win. However, because I published first, I win. The takeover fails.

5. I try to sell my account. In reality, I don't have any way to steal it back. (If I did, so would the attacker. I'm assuming they stole everything.). However, I have no way to prove this to a buyer. For all the buyer knows, I could have a secret third policy.