A suggested rework of followers-only posts and locked accounts: two levels of followership

[PubliqPhirm]

The Problem

I'm putting both these into the same issue because they are tightly related issues.

1. Followers-only privacy requires that you actively maintain a locked account for it to be useful for its intended purpose.
2. Locked accounts are locked for all followers, restricting their reach (that's usually just fine with the owners of such accounts) and requiring a separate public account for users who want their public toots to spread far and wide.

My Solution

My proposal is to have accounts have two levels of following: "subscribed" and "trusted". Subscribed users will see all public posts from the user they subscribed to, while trusted followers also will see the followers-only private posts.

Migration Strategy

Current and future followers-only posts will move to being for trusted followers only. Current private accounts will have their followers converted to trusted followers while current public account will have their followers converted into subscribed accounts.

Discussion of alternate solution

The usual solution to this problem that I see mentioned in discussions of this issue is either to change "followers-only" to "mutuals-only" or to add "mutuals-only" as a new option (see issue #422). However, this has a social problem and a technical problem with it.

• Technically, what I've seen brought up in toot discussions is that a "mutuals-only" doesn't work nicely because your instance does not have a good way to know if a remote user is specifically following you (I'm not sure if this is actually the case or if I'm misinterpreting something, since visiting a remote user's profile has that "follows you" badge)

• Socially (and more importantly), there are plenty of users out there that I would trust with my private toots, but I have no desire to follow all their toots for whatever reason (eg. they toot way too often and would overwhelm my TL if I followed them). Mutuals-only would require I shove all their posts in my TL just to let them see my personal posts.

• ---

• [ ] This bug happens in a tagged release and not on master (If you're a user, don't worry about this).

• [x] I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[Cassolotl]

I have see people say that they'd like to follow someone and see only their public posts, so I think this might work out well for many people!

[nightpool]

While this is a good idea, my gut feeling is that it introduces too much complexity into the modeling of interactions for the average user, and increases the learning curve and overhead and all of that in ways that outweigh it's benefits On Tue, Nov 14, 2017 at 4:31 AM Cassolotl notifications@github.com wrote:

I have see people say that they'd like to follow someone and see only their public posts, so I think this might work out well for many people!

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tootsuite/mastodon/issues/5686#issuecomment-344197749, or mute the thread https://github.com/notifications/unsubscribe-auth/AAORV9iKX5OUjBLYk6lgwN-f6F3bjH8Mks5s2V35gaJpZM4Qcy6- .

[PubliqPhirm]

(Edited OP to reference issue #422 and to improve some of the grammar)

@Cassolotl I just found an old relevant issue, and I'd agree that a mutuals-only privacy setting would miss the mark if you only want to see a person's public posts.

@nightpool I understand your point since the users who would best appreciate having two follower levels are also the ones who are most likely to know a good alt account strategy, whereas explaining "normal" and "private" following to a new user would create confusion (namely, I could imagine a new user thinking "close" followership was like a super-follow instead of a trusted users only option). As Cass said, sometimes you don't want to view a user's private toots. I could filter them out based on likely CW keywords instead, though.

[lapineige]

Any news on that topic ? This would remove the need to setup 2 accounts for (really) private toots + public profile, and maybe raise a bit more people's privacy awareness (as everyone will have to validate "trusted followers", thus they will keep in mind that their private status are accessible to any trusted account).

Bonus: it allows to let bot follow you (for federation purpose) without letting them access your private content (who knows if the bot account does what it claims to do ?

[trwnh]

https://github.com/tootsuite/mastodon/issues/8233#issuecomment-413818515

It sounds like the fundamental change you're asking for is to "show public/unlisted posts when you follow-request someone, then show followers-only if they accept your follow". That sounds like more of a change to how locked accounts and approved follows should work, right?

If that were to be done, then there would need to be new logic to handle unapproved follow requests, hard notifications sent to let people know that someone requested a follow (instead of the soft notification as a counter on the "follow requests" button), and possibly renaming the concept to make it more appropriate -- "unapproved followers" instead of "requested followers"? Under this model, if you want to "reject" an unapproved follower, you would block or soft-block them (since a "remove follower" would be a separate feature request and dependent on #8234 )

https://github.com/tootsuite/mastodon/issues/8233#issuecomment-413831895

I think the exact case would be before Reject Follow, semantically you could have logic for when a Follow has been sent but an Accept has not been received. I just think that it's also important to do the Reject Follow and Undo Accept Follow cases in order to make it robust.

https://github.com/tootsuite/mastodon/issues/8233#issuecomment-414072427

this would be a pretty fundamental change to how mastodon works—you'd have to have "two classes" of followers, and it's not exactly clear from the UI/UX how you'd distinguish between those two. I don't think this is a good idea to implement, unfortunately :(

---

FWIW: there would indeed be the concern of how different software would handle the "follow requested but not approved" state. At least, in order for the remote server to actually fetch that content, it would have to be aware of it, which means that if a Follow is sent then it's still up to Mastodon to respond with an Accept Follow and the Actor's post collection... right? Otherwise, the remote app would have to request those public posts through the Mastodon API instead of ActivityPub.

For all the work that might go into this (and a good bit of confusion), honestly wouldn't it be better to just go ahead an implement a proper access control list? That would allow users to share arbitrary posts with arbitrary audiences, which is basically an abstraction of this -- "approved followers" is, after all, just one possible defined aspect. #7182 is one way of solving this.

[lapineige]

there would indeed be the concern of how different software would handle the "follow requested but not approved" state.

How do them handle it right now with private accounts ?

For all the work that might go into this (and a good bit of confusion), honestly wouldn't it be better to just go ahead an implement a proper access control list? That would allow users to share arbitrary posts with arbitrary audiences, which is basically an abstraction of this -- "approved followers" is, after all, just one possible defined aspect. #7182 is one way of solving this.

This sounds indeed way better (but also much more complex to implement, I guess (?)) and more complete. It would also avoid some work on making both follower statuses clear in the UI, wouldn't it ? (and it would add a very nice feature to mastodon, the same as available in Diaspora, which gives a lot more control on post visibility + reduce the amount of "flood"/"noise" when tooting to a specific category)

[spongefile]

There are two different concepts here: trust/intimacy, and topics.

Google Plus bet their platform on the idea that people would manually maintain friend and topic groups, but apparently in practice people didn't use it much for various reasons:

• it makes you the arbiter of what which of your followers will be interested in
• people fall into multiple categories, especially if you have lists for intimacy, clique, and topic
• people move around in and out of various categories over time
• maintaining this can get increasingly work intensive as you forget who's in which group or missing from a group they should be in
• intimacy and topic weirdly overlap (in-joke for my close sports enthusiast friends)

Overall it looks something like this:

Or like this:

Side note: In theory, if people broadcast to everyone but tagged their toots by topic, followers could self-select topics they don't want flooding their feed (don't show me #politics toots). This is also work intensive but at least puts the decision-making with the person best able to make the decision.

Trust levels are simpler to understand and maintain for the owner of the account. We categorize people by layers of intimacy IRL as well. You gut-level know how much you trust a potential follower, and know when an acquaintance has become a friend. There are things you would toot at people who are interested in your stuff but don't want to flood the fediverse with.

I think "Unlisted" is a bit of a weird concept as-is, because it translates in human terms to "stuff my friends will see and I guess I'm fine with others seeing if they happen to go looking for it", which has a use case that serves the network (please don't flood the local and federated feed) but not so much the user (doesn't make much difference in terms of who sees it). It's also not common on other media, whereas "Subscribed" and "Acquaintances" are.

Even if there's a compelling argument on Mastodon in particular for custom topic lists to toot at that I'm unfamiliar with (isn't the fediverse supposed to help you toot intensively to other enthusiasts about particular topics that may bore your other friends?), I think providing the additional option of "smart" lists like "followers and follow-requests"(subscribers) or "geographically local" would be very helpful.

[trwnh]

@spongefile Google+ "Circles" (and what diaspora* calls "Aspects") should not be used to categorize your own posts by topic. It should be made perfectly clear that circles/aspects are for organizing your followers. The paradigm here is that they are access control lists, meant for determining which audiences can see which posts. It's a terrible idea to expect people to manage other people's interests, and an even worse one to conflate trust with topicality. In the Google+ model, topicality is expressed instead by Collections, which you can follow/unfollow separately from people. By default, following a person makes you follow all their collections, and then you can unfollow certain collections.

The fundamental problem with Google+ and diaspora* was that they reversed the sharing process; you start sharing with a circle/aspect, but there's no guarantee that the other person even wants to see your posts! This led to the misconception that circles/aspects were only for organizing your friends into topical groups, when you were really organizing your followers by access groups. The metaphor got even more confusing on Google+ because each circle had its own timeline, further encouraging the confusion.

---

In any case, I feel that the following schema makes the most sense, keeping in mind the Activity Vocab and how this would be treated with ActivityPub.

Current behavior

1) When you receive a Follow and your account is locked, you must send an Accept Follow to that Actor. 2) If your account is unlocked, the Accept Follow is sent automatically. 3) The Actor is then added to the followers Collection.

Proposed extension

4) Allow the user to create an arbitrary Collection 5) Allow users to add any Actor from followers to that arbitary Collection 6) Allow users to address any arbitrary Collection they have created when choosing an audience 7) Dereference that Collection at the time of delivery, and send to the appropriate inbox of each Actor

---

For Mastodon's purposes (and in my opinion), it would make sense to enforce point 5 as-is, but for a more Google+/diaspora*-like network, point 5 would changed to allow adding any Actor and not just the ones in `following.

• The simplest implementation would be to create a server-defined trusted collection, or to calculate one based on mutual follows, but that would implicitly hard-code the assumption that "mutual" = "trusted". This is in fact what #422 proposed.
• One step above that would be to implement a user-facing flow for manually adding their followers to this trusted collection.
• The final step would be to implement a user-facing flow for manually creating arbitrary collections of their followers, and to display those collections in the Audience/Privacy drop-down.

And of course, API changes necessary for those three steps.

[spongefile]

Gotcha, sorry, misunderstood the intent of "share arbitrary posts with arbitrary audiences" :)

[egypturnash]

So for some historic input into this I want to look at Livejournal’s model for “friends groups”.

You could have an arbitrary number of groups. Some would be stuff like “people I trust to hear about my romantic life” or “people who are pros in the same field I am”. Some would be “people who have said they are interested in my bee-keeping escapades”. People would use them for both privacy AND topic separation.

You could set a post as being visible to multiple friends groups.

And, most importantly, every user always had at least one friends group: the list of people who were shown on their Friends Page, which we would now call their “main feed”.

When a user decided to friend someone, they would be given a list of all their friends groups. It was perfectly easy to say that you want to give that one friend who posted twenty random thoughts a day access to the group for your romantic life without having to see their attempts to use a generally longform place LJ like Twitter before Twitter was a thing.

Ordinary non-technical users navigated this structure on a regular basis, for what it’s worth. Not everyone used it; some people just posted everything friends-only, some posted publicly. It had a lot of nuance for people who wanted it, and collapsed into fairly simple concepts for those who don’t.

I’d love to be able to do this sort of thing again. IMHO it’s one of the things that Livejournal really got right that’s been left by the wayside in current corporate social media models that want to compress everyone into simpler identities that are easier to sell things to.

[shleeable]

I think there is a lot of appeal to the idea of "Follow Groups"... being able to toot at "subsections" is a great idea -- and it's obvious that we all keep collectively coming back to this idea.... Relationships matter

Security 0: Public toot, searchable toots Security 1: Public toot, unsearchable toot Security 1+: Public toot, Instance only Security 2: Locked toot (followers only) Security 2+: Locked toot (Mutual follows only) Security 3: Locked toot (Follow Group Only) Security 4: Group toot (LiveJournal style) Security 5: Private Toot/DM

[dualhammers]

I would like to add a voice to this request as I was about to make a feature request related to this idea, but I think my solution is relatively simple to implement given the current structure.

Feature idea - Mutuals only posts

Origin of concept I don't like having to maintain separate accounts for deeply personal posts and project-based posts and I looked into the idea of locking my account to delineate the two, but quickly realized that locking my account would not solve the problem - I want to differentiate followers into people who are not friends (they like my work and want to see my posts in their home timeline) and people who are

Understanding of current system I think most users don't even understand when or why to use unlisted posts - the use seems to be for posts you don't think will be of interest to total strangers but you do want followers to be able to share with their networks.

Followers Only posts are designed to interact with the locked account system in a way that is not well explained even in the documentation . The assumptions seems to be that followers only posts would be used for personal or sensitive posts meant only for friends and that a locked account would signal this intent.

The result of this technical structure interacting with users (combined with assumptions being brought in from use of Twitter results in two separate sets of assumptions for the two account types:

Unlocked account - My posts are generally for public consumption, followers are to be considered strangers, mutuals are friends. Locked account - My posts are for friends only, followers are to be considered friends, mututal are close friends.

Limitations of current system Uneven assumptions Locked accounts have a lot more assumptions of intimacy associated with them, and this is a problem. One could want to lock an account for many reasons unrelated to making a follow a sign of friendship (for example, you may have a stalker), but the system currently doesn't allow for this differentiation.

I recognize that any solution to this problem shouldn't be onerous to developers to implement or radically change already-established paradigms learned by users. We want to add to not replace what exists if possible.

Technical Execution Add a post privacy rule called Mutuals Only that inherits the properties of Followers Only (cannot be boosted to public timelines, is not listed on public timelines, etc.) but is only sent/visible to mutual follows.

The result would be four post layers

1. Public posts sharing broad thoughts, project updates, announcements for any member of the fediverse
2. Unlisted remains unchanged as the "don't clutter the timeline with this but people can boost if they want" visibility layer"
3. Follower-only posts details that would only be relevant only to followers, such as details about an announcement, or longer posts that require context only followers may have, but you don't want them to be able to clutter the timeline with.
4. Mutual-only posts posts for mutuals which follows the prevailing pattern of assumption among Mastodon users that a "mutual follow" is a sign of friendship. This is where you could make very personal, revealing posts, without exposing them to all of your followers (which can be a big deal if you're a popular user).

Resulting use case I expect this to shift the paradigm as follows Unlocked account - My posts are generally for public consumption, followers are to be considered strangers, mutuals are friends or not depending on how tightly I curate my follows. Locked account - My posts are generally for private consumption, followers are to be considered strangers I've curated, mutuals are friends.

I feel that this solution would allow some users who lock their account (because they sometimes post personal details) to unlock their account and allow casual follows by creating that extra layer of intimacy they were looking for with friends. It would also obviate many alt accounts (popular users or project-based accounts who want a separate account for close friends) by allowing them to curate who they follow and thus limit their more intimate posts to folks whom they have some connection with.

[Xenoslyce]

As someone currently eyeing Mastodon, this would be the thing that would push me to move from Twitter - being able to use one account for all my thoughts instead of having to manage two would be huge.

Really hope this gets implemented or something like #7182 gets added.

[oscarsmendez]

100% need this