Great writeup! A couple thoughts:

First & foremost, which is somewhat glossed over, is the notion that ordinary people will have the knowledge or interest in deploying their own Personal Data Servers. This isn’t really touched on from what I’ve seen in their documentation, despite it being touted as such a major benefit of the architecture.

Very true. There’s a line buried in their white paper that “we expect that most users will sign up for an account on a shared PDS run by a professional hosting provider – either Bluesky Social PBC, or another company” but they very much do tout it as a major benefit. It’s certainly true that the ability to move your data around is a very good thing, and something the fediverse is bad at today, so from a positioning perspective it makes sense to focus on this; their claims that this gives the user power are, um, exaggerated.

due to the high volumes of data involved, there are likely to be fewer Relays deployed instead of many.

Yeah I was in in a discussion where a Bluesky developer suggested that non-profits might run their own Relays … seems unlikely to me, both because of the volume and because of the risk of potentially relaying content that’s legal in whatever jurisdiction the PDS is in but not in the Relay’s jurisdication. Of course Relays don’t have to be for the full network, so we might see more smaller-scoped Relays (although I’m not sure how that differs from a Feed Generator), but if BlueSky and a few others provide the only full-network Relay, that’s a pretty powerful position for them to be in.

Also in that conversation the said that AppViews are likely to be even more resource-intensive than Relays, and so anybody developing an AppView might as well have a Relay as well, so there’s likely to be the same kind of power concentration.

That said I think it’s very good that Relays explicitly appear in their architecture. Relays are also critical for smaller or less-connected instances in today’s fediverse, but don’t get a lot of attention.

Arguably this may make the AuthTransfer network no more decentralized (they go back & forth on describing their approach as decentralized and distributed) than the ActivityPub network is.

Yep. They’ve split the functions of the ActivityPub instance, but it seems to me that they’ve just shifted the power imbalances around, and potentially magnified them.

There was an interesting pair of polls last summer about reactions to Threads and Tumblr. 66% of the respondents were either opposed to or alarmed by Threads federating, and only 10% were supportive. By contrast, only 15% were opposed to or alarmed by Tumblr, and 39% were supportive. It’s just one data point but still interesting!

https://mastodon.social/@mcc/110663712542031369

Thank you very much, that’s a great point – I’ll update the post to include it!

Those are solid requirements to be listed on joinlemmy.org and I would also add another one about moderation policies prohibiting racism, sexism, anti-LGBTQ+ bigotry, Islamophobia, etc. Otherwise, if a user joins an instance that the “official” page recommends and discovers it’s racists / sexist / etc, they’ll see it as a problem with #lemmy as a whole, as opposed to just one bad instance.

And as we’ve seen on Mastodon, if a Black user goes to a site where racism is tolerated and quickly encounters racist sh*t, they leave and tell their friends; ditto for trans, queer, Muslim, etc. users having bad initial experiences. Once that happens a bunch of times the reputation becomes hard to shake. Much better to steer people to sites where they’re less likely to have a bad experience!