Fediverse Report – #109
An essay on user preferences, and how the fediverse’s interconnected network of communities can play into that, as well as some other news.
User Intents
The Bluesky Company (Bluesky PBC) recently announced a proposal to add User Intents to the AT Protocol (ATProto). The proposal allows people to set account-wide preferences how their data should be handled outside the network. It gives people the ability to opt in or opt out their account from a few different things, such as bridging to other protocols or not wanting any of their data being used in generative AI datasets. The proposal is similar to how robots.txt works, meaning that it is a machine-readable format which good actors are supposed to abide by, but is not legally enforceable.
I cover both the fediverse and Bluesky (including ATProto) under Fediverse Report because these networks are deeply interconnected and influence each other. Decisions on one network, like Bluesky’s User Intents proposal, can influence how the fediverse develops and builds their own features. My goal is to help readers understand the fediverse more deeply. By observing how Bluesky’s approaches default user preferences, the fediverse can build their own systems that use its strength of having many diverse and connected communities.
The proposal by Bluesky PBC is as follows:
- People are able to set their preferences for four different categories:
- generative AI
- protocol bridging
- bulk datasets
- public archiving and preservation
- These preferences are account wide. They are valid not only for Bluesky, but for every app build on ATProto.
- The default value is ‘undefined’, not opt-in or opt-out.
- Projects which are intending to use the public data should decide for themselves whether data reuse when the intents are classified as “undefined” is acceptable or not.
- the current proposal is set to lead the way for more granular user preferences, allowing people to specify on an app-level or post-level what their preference is.
Also, some concepts of ATProto that are relevant, which makes the protocol different from ActivityPub:
- On ATProto, a user has only 1 account, and can use that account to log into any service. This is in contrast with ActivityPub, where you need a new account for every service.
- Data on ATProto is public by default, and designed to be accessible. Everyone has full and free access to the data of the entire network.
One thing about user preference settings in social apps is that they are a bit of red herring. The majority of people never change the default settings. Giving people choice is a good thing, but it is impossible force people to choose: the majority of people will just not choose anything. This makes it so that the default value for any preference is hugely important, as it is the de-facto value that the majority of people will experience.
Bluesky PBC tries to avoid this issue by introducing a default “undefined” value. The advantage of using a default value of “undefined” is that Bluesky PBC will not overstep their boundaries and determine the preference of everyone on the network, including people who are not using Bluesky but are using other platforms on the network. The downside is that Bluesky PBC effectively makes no decision at all for the majority of people. Bluesky PBC leaves it to the organisations who use the data to determine how data can be handled if the preference is set to “undefined”. These organisations are likely to value their own interests more than the interest of people whose data they intent to process.
Bluesky PBC has three options here, that all have a downside:
- If Bluesky PBC sets default values for how ATProto account data can be handled it reinforces its centralising role in the network.
- If Bluesky PBC does not set a default value, no decision is made for the majority of people, and it is left to organisations whose goals do not align with those of the people whose data they process.
- If Bluesky PBC sets User Intent not on an ATProto-account wide level, but only on an per-app basis, choices quickly become overwhelming if users must set preferences for every app.
So far I’ve only been talking about Bluesky and ATProto. But the fediverse has a long history of debates, conversations and drama on how to deal with data processing that happens outside of the network. Some high-profile cases include the blowup around Bridgy Fed considering making the bridge between the fediverse and Bluesky opt-out, or the backlash against Searchtodon, which saved user’s timeline locally for searching.
These debates are around data scraping, consent, things being opt-in or opt-out. But one of the struggles that the fediverse has had is to build structural solutions. A significant portion of the fediverse does not consent to have their data handled outside of the network. A persistent problem is that this preference is not expressed in a machine-readable way. This leads to an endless cycle of new developers coming in that are not familiar with the culture who then cross lines of consent and it all blows up in drama again.
Moreover, the fediverse and ActivityPub have a significant advantage on how to deal with the dilemma of setting default values over ATProto. The fediverse is a network that is build up of many different communities connecting with each other. A variety of communities allows for diverse preferences, which can also be expressed in setting default values. And it is a shame that the fediverse is not capitalising on this advantage.
There are communities from whom discoverability is important. Just as there are communities for whom not being easily publicly discoverable is important. These preference can differ within an individual as well: people treat personal photos shared with friends differently from blog articles.
The fediverse can sidestep the question of default account values because people have many accounts on the fediverse, for different use cases. This gives the option to set a different default value for different services. A Pixelfed platform for close friends should set stricter default data-handling preferences. A Mastodon server for blogging platform Medium that has the goal of giving more visibility and reach to its writers could consider setting default values to be more open.
The power of the fediverse is in that there does not have to be a single default at all. Instead, communities and servers should be able to set default values for themselves. This can help shape the tone of the community, and makes it clear what the identity of a community is about. What’s even more powerful is that this only concerns the default value, giving people the ability to set their preferences as they desire. The state of the open social web is such that there are now two protocols in competition with each other. That gives the ability for the fediverse to take ideas from other networks, and improve on them in a way that plays up to the unique strengths that the fediverse has.
The News
Reminder: next week will be FediForum, on April 1-2, and you can register here.
FediverseSharing: A Novel Dataset on Cross-Platform Interaction Dynamics between Threads and Mastodon Users is a new academic paper (currently under review and up on arXiv) that explores the interaction between Threads users and Mastodon users. It takes a dataset of 20k Threads users that have fediverse sharing enabled and compares it to 20k Mastodon users that have interacted with these Threads users. The main goal of the research is to build up this dataset and share it with the community for further research. How sharing a dataset of aggregated user interactions relates to the above essay on user preferences for being included in bulk datasets is left as an exercise to the reader.
PeerTube has done a major redesign for their v7 of the software that came out a few months ago. The organisation now shared the design and development reports that shaped the update.
IFTAS recently had to shut down most of their larger projects due to a lack of funding. One of their projects, FediCheck is now available as open source for someone else to continue with. FediCheck is a deny list management tool that allows server admins to subscribe to external deny lists.
The Lemmy developers will hold an AMA on Wednesday March 26th.
Last week, Ghost made their ActivityPub integration available in public beta for Ghost Pro subscribers. Their weekly update says that now over 250 sites already use the integration. WeDistribute has a hands on with the new features that Ghost offers.
Note: Last week I wrote about the new fediverse platform Forte, and said that the repository did not include an install guide. This is incorrect, the guide can be found here.
The Links
- Website League and the Rise of Island Networks – Sean Tilley/WeDistribute.
- The fediverse has a long tradition of building silly clients for Mastodon. This article has an overview of some of them.
- Two new video tutorials by FediHost, for setting up a GoToSocial instance and configuring a PeerTube instance.
- An update on how search works in music sharing platform Bandwagon.
- A development update for Letterbook, an upcoming fediverse microblogging platform.
- This weeks’ fediverse software updates.
- Fediverse Events hackaton project.
That’s all for this week, thanks for reading! You can subscribe to my newsletter to get all my weekly updates via email, which gets you some interesting extra analysis as a bonus, that is not posted here on the website. You can subscribe below: