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

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

[cypherhippie@chaos.social]

@mcc I’d still be very interested in alternative design proposals, are you willing to share?

And what‘s your take on the recent bsky announcement regarding directory governance?

[mattsheffield@mastodon.social]

@mcc Right now there are people hosted on Blacksky who cannot post because they are banned by Bluesky.

I've been asking Rudy about how independent Blacksky is from Bluesky but have not heard back yet.

From what someone said, it seems that Blacksky is using the Bluesky labeling system which performs moderation. Thus, to be banned on Bluesky means you are locked out on any instance that uses its labeling.

Some more context https://bsky.app/profile/bloomfilters.bsky.social/post/3m2ih4oh64r2v

[mcc@mastodon.social]

So. The thread above. An update.

We finally got a live test of the "Gertrude scenario", when a popular Blacksky user got permbanned by Bluesky. I, using my own PDS and blacksky's website, can't see him or his posts ( https://blacksky.community/profile/did:plc:2aebn3xk5t63net43eeepire/post/3m2iokicegs2b ). What gives?

A lot of people claim this is because Blacksky really is using Bluesky's appview, and gave me a way to verify this looking at headers. This seems to contradict Rudy's previous claims. I've asked Rudy for clarification: https://bsky.app/profile/did:plc:2aebn3xk5t63net43eeepire/post/3m2jve23cf22m

[mcc@mastodon.social]

@tess But

1. Even if Blacksky's appview is limited to the last seven days, or limited only to information Blacksky controls (eg the blacksky pds), I should still be able to see Link's posts, or Link's last seven days of posts. So it seems blacksky's appview isn't being used at all.

2. The test linked above, too, seems to imply I am using Bluesky's appview in all cases.

[bigshellevent@mastodon.social]

@mcc I stay as far away from Dorsey as possible, and they banned LINK?!?!!!

[corax42@mastodon.social]

@mcc Is Blacksky operating its own relay? Is it possible to ban users at the relay level?

[mattsheffield@mastodon.social]

@mcc Link, the banned user in question, is accessible via the raw Bluesky network feed (the "fire hose"). But he cannot be viewed by any server that utilizes Bluesky labelers. Does your PDS?

It seems as though Blacksky does, which is why he can't be seen there. But he can still post. I'm in touch with him and he's posted to me, which you can see here in the fire hose: https://pdsls.dev/at://did:plc:63hvnyjvqi2nzzcsjgnry5we/app.bsky.feed.post

[mcc@mastodon.social]

@mattsheffield The pds doesn't view posts. The appview views posts. You need like five separate components in order to look at a post on Bluesky and every single one of them introduces the potential for censorship. I can't read the site through pdsls that's bonkers

[mattsheffield@mastodon.social]

@mcc The layers are indeed censorship choke points.

What I'm saying is that in this case, it appears to be the labeler of Bluesky that's the issue. Any app view that uses it will suppress Link's posts, even if he's not banned locally.

The app view of Blacksky would hide his posts locally but he wouldn't be banned. This is why he can post but can't see them. The Blacksky app view (the site) is independent except for the labeling.

[mcc@mastodon.social]

@tess I am inclined to give Rudy a lot of leeway because he is clearly moving very fast. I'd rather him engineer than answer my questions and I'd rather not interrupt him while he's engineering a thing I want to use.

But I just want to know what the software I'm using… like… is.

[mcc@mastodon.social]

@mattsheffield *sighs*

I feel like I'm having a lot of repetitive conversations. The thing you are claiming was my conclusion as of last night, but then I was shown an additional piece of evidence, which makes me conclude something different. This was documented in one of the threads I link above, but I link a lot of things above, so I assume you didn't see it. I can explain it, but it would make more sense to just wait for Rudy (who I've asked for an explanation) to explain.

[mattsheffield@mastodon.social]

@mcc I think I did see it, the one referencing the network traffic from bsky.app? I think that's because the labeling instructions are pulled from there and assembled by the client. So it appears to be an app view issue but is actually a labeling one.

But you're right that only Rudy can clarify this