Centralization on trusted servers is going to happen but if they speak a common protocol, at least they can be swapped out. For JetStream, anyone can run an instance, though it will cost them more.

It’s sort of like the right to fork in Open Source; it doesn’t mean people fork all the time or verify every line of code themselves. There’s still trust involved.

I wonder if some security features could be added back, though?

If you’re going to try data reduction and compression, always try compression first. It may reveal that the 10x reduction you were looking at is only 2x and not worth the trouble.

Reduction first may show the compression is less useful. Verbose, human friendly protocols compressed win out in maintenance tasks, and it’s a marathon not a sprint.

As a corollary, if you try to be too clever with your data reduction strategy, you might walk yourself into a dead end / local maximum by making the job of off-the-shelf compression algorithms more difficult.

> If everyone is on one server (remains to be seen)

Even internally, BlueSky runs a number of "servers." It's already internally federated. And you can transfer your account to your own server if you want to, though that is very much still beta quality, to be fair.

You're not really "on a server" in the same sense as other things. It's closer to "I create content addressable storage" than "The database on this instance knows my username/password."

And if you're curious what your Bluesky server is:

  DID=$(curl -s https://<username>.bsky.social/.well-known/atproto-did)
  curl https://plc.directory/$DID | jq '.service[0].serviceEndpoint'

Or if you're using a custom domain (a la example.com), you can get your DID from the DNS:

  dig +short _atproto.example.com TXT

Thanks for this! I'd never checked. Turns out I'm on https://morel.us-east.host.bsky.network. I do want to host my own PDS someday, but then I'd be responsible for keeping it up...

Indie hosted PDS is on my list as well.

I'm also currently trying to understand the tradeoffs for did:plc more. It's unclear to me just how centralized it is. Will it always require a single central directory, or is it more like Certificate Transparency? Based on what I've heard about the recover process, I believe it's the latter, but I still need to dig into it more.

I don't know myself, but given that the discussion there, from what I've heard, is along the lines of "should be moved into an independent foundation," my assumption is that it will always require a directory. But this is probably the part of the tech stack that I know the least details about.

We've seen this over and over. If you do things the "right" way devs just don't show up because it's too much work.

Depends on what the right way is to be honest. If the "right way" is moving the project into zero-knowledge proofs territory, it does push out a lot of the developers. It is not that cryptography in general is pushing people out in that case but ZKP complexity is.

Or why can't one verify a msg on it's own isolated from all of the other events on the PDS.

The full Firehose provides two major verification features. First it includes a signature that can be validated letting you know the updates are signed by the repo owner. Second, by providing the MST proof, it makes it hard or impossible for the repo owner to omit any changes to the repo contents in the Firehose events. If some records are created or deleted without emitting events, the next event emitted will show that something's not right and you should re-sync your copy of the repo to understand what changed.