Proposal for Mastodon Fork Posting Privacy

31 January 2021

Preamble

This is a proposal written by me, a white trans woman who generally finds social media works in a way that my brain finds unappealing. "Sandpaper" is a word I would use to describe experiences like Twitter, Facebook, and mainstream Mastodon.

This proposal will contain not only a concept for the reconfiguration of posting privacy features in Mastodon forks, but analysis of problems seen with current implementations of select features in other forks.

Including amongst these will be some talk of the now-defunct Monsterfork, specifically the version from before the Monsterpit Reboot.

I am, however, one trans woman in my late twenties, and this is nowhere close to a comprehensive analysis. Think of it as some actual thought put into things such as privacy, user safety, and anti-harassment. Which is more than can be said about mainstream mastodon development.

The Eugen Problem

"But," one may prod me, "why are you titling your proposal as being aimed towards Mastodon forks, when you could have it be a direct proposal to Mastodon itself?

The answer is that Mastodon development is headed by someone who has repeatedly shown that he has zero interest in safety, and just wants to clone twitter while making it feel less corporate. I do not expect Eugen to change, either his mind or ideology. It's a waste of time, in my opinion. I would much rather encourage others to write their own forks more effectively.

The Current Perception of Posting Privacy

Mastodon currently operates in a system with four posting settings: Direct, Followers-only, Unlisted, and Public.

Each of these allows restricting further while replying, which is a good feature that allows taking a thread somewhere a little more private if you have more you want to say. Strictly speaking, one isn't supposed to be able to open up a thread's privacy in replies, but servers are sometimes inconsistent in their implementation. Still, it does not (to my knowledge) break privacy in federation - just makes threads look weird.

A fundamental issue we can begin with is that Mastodon takes posting and builds it from the wrong direction. "Public" posting is the default, assumed form of interaction; Your posts are visible to literally anyone who federates with the server. "Unlisted" stops the post from appearing in the federated or local timelines, but the post is still accessible to anybody. "Follower-only" then makes it only accessible/visible to users who are following you. "Direct" removes the post from all timelines, only showing up in the mentioned users notifications or DM drawer.

For the purposes of this analysis, we will build a table showing how each posting privacy level corresponds to what circle of people can see your posts.

For the purposes of analysis and design, we will define these circles of access as:

• Mention: Any user mentioned (with an @) in the post.
• Follower: Any user following the poster.
• Profile: Any user able to see your profile, if they have a link to the post.
• Federated: Any user anywhere.

We could get more granular in describing where and how the post appears in timelines (Home, Notifications, Direct Messages, Local, Federated), however this will hopefully prove somewhat unnecessary by the end of my proposal.

Gaps in Perception

There are actually several problems with this analysis that are not immediately apparent. For one, there is actually no correspondence whatsoever to something being on your instance, as opposed to federating onto other timelines. For this purpose, we are going to propose several additional circles of access that are left out of the Mastodon developer's conception of privacy.

The first most obvious one is the "Local" circle, which both Glitch-fork and Hometown have conceptualized. It can be defined as:

• Local: Any user on your instance.

We can expand the concept of instances in two interesting ways. First, there is the concept of "neighbouring" instances. For example, back when Monsterpit was still active, the maintainers also ran a Friendica instance called Creature Cafe which could be considered a "neighbouring" instance. You can also think about a web ring, where there are adjacent sites in the ring, which are both "neighbours". The easiest implementation of this is a whitelist, maintained by the administration, that defines which instances are considered neighbours. Thus:

• Neighbour: Any user on an instance in the neighbourhood.

One smaller addition is one that i have seen griped about in private a lot, but is pretty sizable once considered. Right now, there is no way to differentiate between followers and mutual followers. Mutually following with a user implies a mutual interest in involvement with posts, and trends towards more indication of who someone's social group is.

• Mutual: Any user who is both following and is followed by the poster.

With this in mind we can re-analyze.

Re-analysis of Default Posting

What becomes abundantly clear reanalyzing through this lense is that the default posting properties for Mastodon not only leave a large amount of privacy circles completely unattented, but they specifically leave the largest safety net for online posting completely unattented: The local post.

Attempts to Implement a Local Post (Spoiler: I am Unsatisfied)

There have been two major attempts to fix the Local Posting problem in Mastodon forks (that I am aware of): Both Glitch-fork and Hometown intoduce an option called "Local-only" that prevents a post from federating beyond the instance.

This, to re-emphasize, does not mean that your followers can read your post. This means that the posting privacy is in no way modified, other than, anybody from and external instance is completely chopped off.

What you end up with is a group of settings like this:

What is of note is that Local-only is a modifier on a post's settings. Whatever settings you were operating at, you've now restricted it to local. But this has some major flaws:

1. It breaks mentions. This can allow bad-actors to snitch on a user elsewhere in the fediverse to their entire instance without that user knowing why. Yes, you can already do this by dropping a link to a profile, but anything that expediates harassment is bad in my books.

2. Followers only get to see the post if they are on your instance. This doesn't actually solve the problem of wanting to post to a wider circle without wanting to post federated.

Monsterpit Classic

Monsterpit was a Mastodon instance tailored towards furries, queers, and monster-fuckers who wanted a safer and more private area to indulge in socializing and erotica (in other words: sexually explicit). I was never close to the development team of Monsterpit, so i am mostly working off my recollection as a former user. The site suffered a major crash, after which it was rebooted with a new fork based on Glitch-fork. What we want to analyze is a feature of the original, pre-crash site, which was a successful implementation of a Local posting privacy.

What makes this setting significant is clear in the verbage, i think. It is a "local" post, but not a "local-only" post. As seen from the chart, it effectively has every feature of an unlisted post, while also being visible by any user of Monsterpit on its Local timeline.

How this could be useful on an erotica-focused instance is fairly simple. If one published an erotic novel, for example, that you maybe don't want to tell the entire fediverse about, but still want to let all the horny monsterfuckers know about... problem solved.

This does not, however, fit the rationale that Hometown and Glitch-fork put behind their optional setting: You aren't able to make a post that is for Monsterpit users only.

Not the Actual Proposal: Fully Cellular Privacy

The easiest solution to this problem would be to try and create a similarly covered table to what Mastodon's naive design assumed, a single setting for each ramped-up level of privacy. What that looks like is this:

The term "cellular" was coined by a friend while we were discussing this problem. The point is to refer to how a social organism develops and grows, and that a wider spread like this fully embraces the "cellular structure" of an organism such as a federated social network.

The term "fully" is emphasizing how we have one setting for every option, which clearly allows wide control. However, this also has some problems

1. Nobody wants to choose a drop-down of seven posting privacy settings: This is an extremely sensible problem. One of the biggest difficult of creating good user experience is making sure that you don't overload the user with utility. Giving a user seven options is, frankly, absurd. Even Monsterpit Classic's five options felt like stretching it. I think it's fair to say that Mastodon's decision to provide only four options is actually fairly good from a usability perspective. The development team just decided on an odd third setting. (Unlisted.)

2. No ability to restrict further: Glitch-fork and Hometown do make a solid argument in wanting to have strictly local-only posting available for organizing very instance-specific content.

Which brings us to my true proposal.

Optional Cellular Privacy

Taking a leaf from Hometown and Glitch-fork, instead of making every single possibility its own setting, we instead provide advanced options for several main posting modes. These options would be available when their associated, less-restricted option is selected.

I have also renamed "Followers-only" to "Followers" for consistency of terminology.

Of note here are the default "Direct", "Followers", and "Public" settings from mainstream Mastodon settings. We have also taken the "Local" setting from Monsterpit Classic and replaced "Unlisted" with it.

We then provide the following options:

• Mutuals-only: Prevent a "Followers" post from reaching followers whom you don't follow.
• Unlisted: Prevent a "Local" post from showing up in the Local timeline.
• Local-only: Prevent a "Local" post from federating outward.
• Neighbours-only: Prevent a "Public" post from federating to non-whitelist instances.

All of these settings have an important exception, which is:

A mentioned user will always have the post federate to them.

As described earlier, this is to mitigate harassment.

Conclusion

I don't know what else to write, that's about all I have I guess. I hope if you contribute to creating federated social media, you'll take these tables into account and think about the possible ways to provide granular control of publicity without needing to implement complicated posting lists like Facebook or Google did.

I think it's important to mitigate harassment whenever possible. I think it's also important to give people a chance to exist as publicly or privately as they wish to, without making them feel cut off from their friends or social groups just because they don't want to fight with agonizing tech bros on the federated timeline. Especially for queer people like me, that's extremely exhausting.

I know this won't change Mastodon. I don't expect it to change anything. But I hope it stirs something in you. I hope it makes you want more.

Because you deserve more.