jdp23

joined 1 year ago
[–] jdp23@lemmy.blahaj.zone 2 points 8 months ago

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.