Hi!!! I’m a strategist/entrepreneur/software engineer/activist, focusing on the intersection of justice, equity, and software engineering. I’ve been on the fediverse for a long time and am currently checking out /KBin. @jdp23@indieweb.social is my main account on

  • 9 Posts
  • 23 Comments
Joined 2 years ago
cake
Cake day: June 5th, 2023

help-circle

  • 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.






  • Agreed that figuring out the right action is important! It’s clear from the conversation so far that a lot of instances are going to defederate, and a lot of instances are going to federate, so any strategy needs to take that into account.

    I talked with a lot of people about this when I wrote Should the Fediverse welcome its new surveillance-capitalism overlords? Opinions differ! and don’t think it’s the case that we share the same goals. Some people see increasing the size of the ActivityPub network as a goal in and of itself (and generally support federation); others are in the fediverse because they want nothing to do with Facebook or Meta (so unsurprisingly support defederation). And some people have a goal of communicating with people on Threads – friends, relatives, celebrities, etc; others don’t. So again, these different goals are something to take into account.

    Wanting to stay federated DOES NOT mean the user wants to help Meta or thinks that Meta is here for our benefit.

    That’s correct, but many of the people I’ve seen arguing in favor of federation do seem to think Meta’s looking for a win/win situation where the fediverse benefits as much or more than Meta. And conversely many would argue that wanting to stay federated means the user is helping Meta whether they want to or not.