There are different types of attacks possible though, most broadly you can divide them into "design holes" and "implementation holes". This seems to be about preventing a design hole, and those you need to prevent with architecture/design, you can't just fix those once the implementation and documentation is done.

Not the parent poster, but the cynical impression I had from very early on for DID is that almost all of its complexity and much of the reason its space is full of half-working implementations rather than working ones is pretty obviously because it was designed to be an abstraction layer on top of "namecoins" and when the "namecoin" dependency was removed (for good reasons) there were not enough good ideas for what to replace that dependency with, sort of intentionally leaving what was left of the design in a sort of guaranteed perpetual state of half-implementation (including implementations based on some of the original "namecoin" ideas).

Much of DID itself is basically a standardization of the idea behind Keybase, ie, using control of a private key as a marker of identity.

This in itself is a pretty good idea (with some bad usability, but at least technically interesting)

DID falls over because it has a bad interop story, and much of it is based on crypto-based implementations (again, technically interesting but bad usability plus a monetary incentive to go after your details).

I agree that the ATProto situation described is ridiculous. However the situation with AP is not nearly as cheery as you describe. The protocol commits the exact same sin, essentially baking in the assumption that any given ICANN DNS entry will only ever be controlled by a single entity for all time. Real world implementations then associate keys with nodes using a TOFU scheme (which makes perfect sense) and if the domain ever changes hands (thus the key changes) all sorts of stuff breaks in frustrating ways.

Even worse are the assumptions that a given node will never migrate between DNS entries or appear at multiple DNS entries simultaneously. In practice this comes up all the time because people regularly stand a node up on a cheap VPS using an off the cuff domain. Then some time later they either forget to renew the domain or have second thoughts about it.

While I appreciate that it's always easy to criticize things in hindsight there's no lack of aggravating real world problems related to the way AP models identity.

Just to be clear, this is specific to did:web, did:plc does not have the same downsides (it has different ones).

I’m trying to understand how “burning” works here. If I understand correctly:

1. Someone has a domain, example.net. They set up a did:web:example.net, and a handle @example.net pointing to it.

2. They deleted their account and let the domain expire.

3. I register the domain, but can’t set up did:web:example.net again. But I assume I can still set up did:web:mynewdid.example.net, and then point @example.net to that DID instead.

I won’t have access to the original account, but I will be able to use that domain as a handle for a new one.

(This, of course, is only my assumption. I’ve been able to switch my domain from one did:plc to another, but I haven’t tried it for did:web.)

I see this as a mistake caused by really poor docs that should explain what to do and warn not to do the thing this person did.

It's also true that big instances have a lot of power and it's going to require a lot of growth of alternative instances to fix that, which will take time. At least it's possible, though. It's an intended outcome.

Any system that can ruin a spammer can also ruin someone who isn't a spammer, since the system can't tell the difference.

Bluesky is designed the way it is because of scale. How do you make a p2p app that can handle hundreds of millions of posts per day without beefy servers helping? Bsky is designed so that the microservices themselves can be decentralized and so multiple different types of apps can be built on the same protocol/infra.

Obviously, it’s early days, and hopefully there is even more experimentation in the p2p space. But atproto architecture is a very fair experiment in this space. I can store my data on my own server, use a client app I wrote, subscribe to a specific aggregation/feed service I prefer, use the moderation list I want… all while still being connected to the larger protocol & network. It’s pretty neat.

So I agree with you that they should work like email -- but I've always said that Mastodon is better because it is like email; aka the power is in the nodes.

What do you think is wrong about Mastodon? Genuinely curious because I also am super skeptical that ATProto brings anything that we really need.

Email is the prime example of federated communication. From protocol inception to painful expansion and aging protocol all until corporate apropriaton. But I still think federation is the way forward, absolute centralisation is bad I'll let you figure why, but absolute decentralization is also bad, limitations due to its nature, unusual working for most users... Meanwhile federation is right in the middle, and users already use it with email without even noticing!

We don't need large scale social networks in the first place. The Discord model of small communities is the way forward. Keep groups small enough for natural human social rules to apply. Slows down global dissemination of information for sure, but that's what the news is for, and anything important will eventually travel between communities anyway.

I don't disagree, but I'm baffled that, with P2P as your preferred outcome, your orientation toward federated infrastructure is one of opposition rather than support. It feels philosophically confused to me; they're your natural allies, they're a step in your preferred direction and they have an instance of real world success (well, to a degree) which is important. Whatever theory of change motivates this form of criticism of federated services can't be one that's, say, intentional or strategic about outcomes. It feels more first principles.

One might also ask why P2P thesis statements only ever show up deep in the weeds in comment sections in response to the fediverse when logically speaking they would make just as much sense if not more in response to, say, any post about Facebook as a company or social media writ large, or business news about acquisitions, consolidation of web infrastructure into fewer hands, enshittification, or escalations of control over platforms.

Again, I'm fully on board with the dream of P2P but it feels like Buzz Aldrin criticizing Neil Armstrong for not doing enough to bring humanity into the space age.

Unfortunately, the swarm is 99.99999% advertisements for penis enlargement pills. How can a P2P system filter them out? A federated system relies on each admin to filter them out. A centralised system does even better, relying on a single dictator to filter them out. A P2P system requires every user to filter every spam message, together consuming far more effort than the spammer needed to send it.

Thanks for the response Nora.

Because of your blog post I went through the process of setting up a did:web account myself this afternoon, and it was painful. Eg, I found a bug in our Go SDK causing that "deactivated" error (https://github.com/bluesky-social/indigo/pull/1281). I kept notes and will try to get out a blog post and update to 'goat' soon.

We've also been making progress on the architecture and governance of the PLC system. I don't know if those will assuage all concerns with that system immediately, but I do think they are meaningful steps in reducing operational dependency on Bluesky PBC.

You can host your own instance, but resolving forks is not self-authenticating and requires some central trust (because of the 72 hour rollback window for higher priority rotation keys). Not counting that, you could essentially run your own fully independent instance where the worst that could happen is that you lack some newer updates to people's did documents (but anyone can upload them since they're self-authenticating). Some people do run their own instances for caching reasons, but these just ingest operations from the official one.

In terms of "credible exit", if the community at large could decide to move to a different PLC host, it would be technically possible for everyone to switch over.

Worth mentioning that Bluesky PBC is relinquishing legal control over the PLC and spinning it off into its own entity based in Switzerland.[1]

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

No, did:plc is centralised, not federated or anything. The whole ecosystem relies on a server at Blue Sky PBC

> Form should follow function, not the other way around.

According to whom? It's their personal website, they're allowed to place value on whatever they want.

Backseat moderating is also against the guidelines. If you believe the comment needs moderator attention, flag it. It's pretty ironic you can't say this rule without breaking it

I wish there was a rule against rule lawyering. Those comments are way more annoying than gp. (queue recursive replies)

I'd like to add to my sibling comments that this blog's design is so atrocious for its readability that it deserves to be called out.

In fact, I'd like for such a comment to be at the top here, so that I can decide to avoid following the link until I have read enough comments to determine whether it's worth it.

I wonder if it renders differently for different people.

No, OP is saying that they have over-engineered the protocol, and that this acts as an *effective* barrier to participation, regardless of whether it was intended or not. Bluesky's protocol is focused on twitter-scale use-cases, where every node in the network needs to be able to see and process every other event from every other user in able to work properly. This fundamentally limits the people who can run a server to only the people who are able to operate at the same scale.

So can ActivityPub, as far as I know. Most of the social coding projects agreed upon a shared vocabulary: https://codeberg.org/fediverse/delightful-fediverse-experien...

That is a really cool project, thanks for posting

Nice to meet a third person who both works with blockchain and understands distributed systems ;)

I'm building a place review system.

Is there an advantage to using this protocol instead of a more application–specific one? Perhaps the shared identity?

Not exactly—a PBC is allowed to "balance" shareholder profit with "stakeholder interests. But at the end of the day, the money is still coming from the shareholders, and they're still looking for a return. They're required to be transparent, but that's about it. And there aren't really any penalties for not complying either.

How many users actually care about decentralization?

Unfortunately most people couldn't care less. Bluesky has been lying about being decentralized since day 1, and yet they have millions of users.

The article that they are having trouble reading due to its format?

It is in a sense by design because the focus was creating a decentralize-able/federate-able protocol and infrastructure that can scale more or less indefinitely first and foremost, community second.

The community is working on actually decentralising the network now that things mostly "just work" (assuming you are using did:plc/generally a happy path user).

- Building out PDS communities that are trusted takes time and nowadays there's a few outside of bluesky PBC (one or two big ones and a bunch of smaller ones). People are eager to move off because a lot of users really really don't like bluesky PBC leadership but it's a matter of waiting for these third party communities to reach critical mass.

- Relay infra is already pretty much decentralised. Lots of people still rely on the main relay but it's trivial to use a third party relay and there's more of them than you can count.

- There are a lot of really high quality third party clients and afaict a lot of users do actually use third party clients but there's basically no metric for tracking these stats.

- Appviews are expensive currently and there's work on making them easier to host but there's already one "full" alternative appview for bluesky.

- There are a lot non-bluesky apps/services that are genuinely high quality experiences and they are gaining their own communities.

The main technical barrier to true decentralisation outside of improving UX is introducing other did:methods and/or spreading trust of did:plc across the community (ex: clustered via raft or paxos across major operators) but there's just not a reason to pursue this over the other fires that need fighting in the ecosystem right now (and keeping did diversity low reduces another source of complexity the space just doesn't need to tackle yet).

--------------

TLDR: it is intentional because the goal is to in order of priorities:

1. get the architecture for eventual decentralisation right.

2. make it exist.

3. make it good.

4. make it easy to use for normal people.

5. build community.

6. focus on decentralisation.

Decentralisation in theory is the first priority but in practice it's the last priority. Being able to decentralise is always the utmost importance but forcing it to happen is not ever the top priority because that's on the community, not on the developers.