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

[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

[mastodonmigration@mastodon.online]

@ikuturso @benroyce @txtechnician @mcc

In general, their finances are very opaque. Some are saying that the $15M can last them for 2 years, but it is hard to understand how a 25 person silicon valley company with 100 contract moderators, and no revenue can be running at $625K per month. In any case, as mentioned above, either they have to start raising more money or they have some other undisclosed source of funding.

2/

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

https://bsky.app/profile/cypherhippie.bsky.social/post/3ltjyieagvs25

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

https://docs.bsky.app/blog/plc-directory-org

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