Add a "soft" follow-authorization option to accepting follow requests. #8682
Conversation
boy I hope it's everything
i am such an airhead omfg
|
see #5686 for my concerns on this issue and why i believe it shouldn't be implemented. Overall, this would add another layer of complexity to mastodon already-hard-to-understand privacy model. Many users would be upset that they couldn't have "fully followed" friends with a non-locked account, or would like the option to post to all of their followers sometimes, rather then only being able to post to "fully followed" users or publicly. I don't think the confusion this would generate would be worth the small benefits of not having to maintain a second account (which many users would do continue to do anyway because it gives them more granularity and control). On an implementation level, i have some concerns about the ActivityPub representation of partial followers/full followers and i don't think your proposed solution works on a more general level (since some servers might dereference the followers collection and use that instead for distribution) |
|
You can see the list of errors by clicking on the "details" link next to a test:
|
|
It might be possible to treat the "unaccepted follow request" as its own "soft" state by sending public posts to anyone in the Follow Requested collection (is that a thing?). In other words, requesting a follow should show you someone's public posts until they approve your follow request; rejecting your follow request would federate out, soft-accept would not change anything for them, but updated servers could keep track of these follow-requested users and send public posts to their shared inboxes. That'd be fully backwards-compatible, but perhaps undesirable for people who don't want their public posts to be tracked? Although, I would argue that if this were implemented as such, it wouldn't be too different than any person browsing the already-existing public profile, or subscribing to their RSS feed. |
I didn't see anything else in the issue that you didn't mention here, so I'm going to assume you linked it just to connect the two rather than that I'm missing something. It doesn't appear to have caused any confusion so far, although this is admittedly with a small (but not especially technical) sample size that wouldn't be considered statistically significant. I also don't understand the statement that people can't have "fully-followed" friends with a non-locked account, since that's what all followers of someone with a non-locked account would be? And "post to your followers but not public timelines" is already covered by the Unlisted privacy level. If I was trying to cover every single case of desired granularity in limiting who can read what, this would be a very different feature PR, but I'm not interested in replicating anything like the suggestion in the issue you linked to. As this feature stands, it's intended to allow people who already desire and use the follower approval feature the option of having their publicly readable posts more widely accessible, without compromising the usefulness of private posting. Currently, there is no way for people to access your ostensibly public Unlisted posts other than following you - and getting all your locked posts, too - or reading/scraping your public account page. This is intended to account for the fact that the Unlisted privacy status, as it exists now, has almost entirely wasted potential functionality. This option doesn't apply to people who don't want to manually approve their followers at all, as it doesn't display any differently in the interface so there are no social status indicators to be concerned with.
I'm not by any means an expert on AP and am completely willing to accept that there's problems with my implementation, but I don't actually understand what you describe here as a potential situation, so I'm not sure what the problem you're commenting on is - which I do want to know and understand, because if it's a significant issue I would like to try to fix or account for it. |
I can see some merit in this idea, but it would be extremely unintuitive from the perspective of the person who is actually using the feature - that is, the one who has their account set to Locked so that they have to approve all follower requests. They would (quite reasonably) expect that people who haven't been approved by them as a follower are not following them. This is a feature for the approval side, not on the requester side, so changing how the requester side works is, I think, a different issue. |
Can I just ignore the code climate errors that are on pre-existing code rather than my commits? |
As an example, I have an unlocked account with a very large number of followers. However, i'm nervous with that number of people having access to my private posts. Even though I don't care who follows me publicly, being able to control who has access to my private posts would be very useful. But to be clear, I'm not saying the pull request should be modified to include these things. I'm saying that, if we merge this pull request, these are the questions users are going to have. We're introducing a new concept into mastodon's mental model (a follower that can see your public posts but not your private ones), and we have to make sure it's coherent to users—that the mental model "makes sense". |
I wasn't describing a potential solution, I was only describing a potential problem. Let me go into more detail:
I'm not super sure what the correct solution is here, although a couple were proposed in the ticket I linked |
I said situation, not solution, sorry for any confusion from my word choices. 😅 What I wanted to know was the specific problem, which I think you've probably addressed - but I'm going to have to read over all of your comments in the morning with a fresh view. |
|
It seems to me (and may not seem to everyone else, I'm just throwing it out there) that a resolution to that problem would be to modify the API to present three endpoints:
where |
Yes, but your PR also introduced some errors. Clicking on "Details" will lead you to https://codeclimate.com/github/tootsuite/mastodon/pull/8682. There, only new (from your PR) errors are displayed by default. |
|
@JMendyk you'll see that not all of those code climate errors are for the lines changed, some are for surrounding lines. @TheInventrix The rule for CodeClimate is "use your best judgement" |
|
@nightpool Ahh! I see what you mean now. I have some good stuff to think about - on the positive side, I think all of the concerns presented are fixable, although fixing the technical issue raises the issue I was hoping to avoid of having visibly separate follower types. @joyeusenoelle's suggested solution sounds reasonable and effective, so I'm going to work towards trying it out while thinking about how best to handle the added complication of visibly grouping followers into access tiers from the user perspective. Most of my ideas so far have been along the lines of drawing a clearer connection between the Private and Unlisted privacy levels to the two access levels, since that effectively eliminates the issue of having to learn additional information, but I still need to work out the social issues. It sounds like adding an auto-semi-auth function would be desired, which is a little ironic because that was my original goal, but it turned out to be a lot harder so I switched to this implementation.... Ah well, more motivation I guess! |
|
I have often longed for the ability to restrict private content to certain folks while still allowing everyone to follow public posts. I believe the overhead of maintaining separate accounts for this purpose is cumbersome and inflicts unnecessary friction on both sides. So I love this idea and think it would be a huge benefit to the federation. Bravo, @TheInventrix! Regarding terminology, I find terms like “soft” and “Semi-Authorize” to be obtuse — they don’t convey enough information to understand what they actually mean. For terms exposed in the user interface, I think “Public Posts Only” or even just “Public Only” would be much more clear and direct. Looking forward to the next iteration, @TheInventrix! 😁 |
I'm in the same situation. I have tens of follow requests from random people: some are acquaintances, some I don't know at all... none of them I want to share my private posts with right now. So I've granted the "follow request" property only to a privileged few and even there: a bunch of those are there because I didn't know that followers could see my private posts (and I'm ashamed to say i don't even know how to revoke the follow request privilege). So yes! This! I've been hoping for this, but I never even dreamed there would be an actual PR to make that work! That's great!
I agree that focusing on existing nomenclature would be better - "public follow request" or "private follow request" maybe? But I don't care which color the bikeshed is. ;)
Same here! :) |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
This feature adds a third option to follow requests which allows permitting other accounts to follow only your public and unlisted posts, without giving them access to your private posts. The purpose of this is to both facilitate greater control of your private posts and to encourage greater federation of public content by potentially allowing a larger number of accounts to follow said content.
It downgrades to incompatible instances while preserving intended private post access limitations by the admittedly less-than-ideal method of having softauth be send through RejectFollowService, so that remote instances who do not support the feature will treat it as an ordinary follow rejection and not give that account any posts. (The alternative would have potentially granted them access to any private posts via internal fan-out of received posts, which is an unacceptable effect.)
I chose what I felt was the best terminology and iconography I could come up with for the feature but would happily change it with any suggestions for clearer alternatives.