New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
PubliqPhirm opened this Issue Nov 14, 2017 · 10 comments

Comments

Projects
None yet
9 participants
@PubliqPhirm

PubliqPhirm commented Nov 14, 2017

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).
  • I searched or browsed the repo’s other issues to ensure this is not a duplicate.
@Cassolotl

This comment has been minimized.

Cassolotl commented Nov 14, 2017

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

This comment has been minimized.

Collaborator

nightpool commented Nov 14, 2017

@PubliqPhirm

This comment has been minimized.

PubliqPhirm commented Nov 15, 2017

(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

This comment has been minimized.

lapineige commented Aug 18, 2018

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

This comment has been minimized.

Contributor

trwnh commented Aug 18, 2018

#8233 (comment)

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 )

#8233 (comment)

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.

#8233 (comment)

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

This comment has been minimized.

lapineige commented Aug 18, 2018

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

This comment has been minimized.

spongefile commented Aug 19, 2018

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:

untitled 2018-08-19 13-08-33

Or like this:

untitled 2018-08-19 13-56-07

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.

untitled 2018-08-19 12-40-55

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

This comment has been minimized.

Contributor

trwnh commented Aug 19, 2018

@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

  1. Allow the user to create an arbitrary Collection
  2. Allow users to add any Actor from followers to that arbitary Collection
  3. Allow users to address any arbitrary Collection they have created when choosing an audience
  4. 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

This comment has been minimized.

spongefile commented Aug 19, 2018

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

@egypturnash

This comment has been minimized.

egypturnash commented Sep 13, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment