Decompose "follow" into "follow request" and "allowed follow"

[temujin9]

Is your feature request related to a problem? Please describe.

Currently, blocking does not remove a follow, because follow is a property solely of the following account. This means that blocking does not break the follow, breaking an expectation that Twitter built ("soft-blocking"), because one user cannot change another's account.

Describe the solution you'd like

Make following a two-phase process: follower makes a follow-request, and followed makes a follow-accept (which can be user configurable as default-yes or ask). Either being removed breaks the relationship unilaterally. Blocking removes your follow-accept or follow-request as part of the action.

[DavidBuchanan314]

I think this is a good proposal.

I don't know how it works at the protocol level, but in Pleroma (activitypub) I have the option to make someone unfollow me directly, from their profile page, without having to do the soft-block dance. I think this is a cleaner UX, but having the block-causes-unfollow mechanic is also still a good thing. (and this proposal could enable both/either)

[DavidBuchanan314]

One question mark is, how would "default yes" mode work?

The follower has no mechanism to directly notify the followee's PDS (assuming they're different PDSes).

I'd suggest that there be some AppView API to list pending follow requests. In default-yes mode, the client would request this list periodically, and create the required "allowed follow" records as necessary.

This would mean that you can't follow someone on another PDS while they're offline. (but I suppose if they're offline, they're also not posting anything, so there is nothing from them to see in your following timeline anyway)

[temujin9]

That sounds reasonable. Perhaps you can set follow intent and navigate away, but it will show it with some form of "in progress" marker until the followed PDS is online again.

[pfrazee]

This is a protocol discussion, so I'm going to transfer this issue to https://github.com/bluesky-social/atproto

[pfrazee]

Passing to @dholms and @devinivy

[naim94a]

I might be missing something but I think that it would be confusing for users.
If users can make it possible to require approval for followers - it would make it feel like a private network while their data is actually still public.
Wouldn't it be better to expect a PDS to implement "soft-block"?
This can be enforced by policy - a PDS found not to implement it could be defederated.

[DavidBuchanan314]

The effects of blocking mechanics are not enforced by PDSes, they're enforced by AppViews.

It might be confusing for twitter users, but it is very familiar to fediverse users - post visibility and follow approval are distinct controls there. It's down to the client UI/UX to make sure users understand what's actually going on.

[dholms]

If we were to allow some mechanic similar to a soft-block - this would be it

However this somewhat substantially increases the complexity of follows & as @DavidBuchanan314 points out, requires some trickier data flows - either a PDS now has to be notified of another PDS's behavior so it can auto-approve it, or we have to do something smart with AppViews & clients.

I'm not sure the feature is worth the complexity. I also don't see this feature as being core to the public broadcast social mode. "soft-blocks" - tho used as a feature - are more of a quirk of Twitter's particular implementation. At the end of the day, following or not, you can easily view the user's posts. Many feeds may not even take follows into account when serving content.

[gojomo]

The idea of bidirectional on-the-record expressions-of-intent seems beneficial & perhaps even necessary in an open/decentralized system.

I'd suggest more-neutral language than 'allowed', though, which implies more enforcement than may be realistic in actual public spaces. For example, a controversial public official who declares that a reporter's "follow-request" is "not-allowed" can, should, and will have their intent ignored.

I'd even suggest softening 'request' to be less about a step/transition than about a state-of-world: "follow-desired". It's then still a true-declaration by its issuer, even if overridden/limited by other declarations/politeness/whatever, or if its effects vary by time/others-actions.

[pfrazee]

Another way to do soft-blocks is simply to create a soft-block record. Rather than requiring bi-directional confirmation of a follow, you default to allow but enable the target of a follow to publish a denial of the follow.

@gojomo One way to diversify the ruleset around an account is to establish sets of flags which distinguish their role of operation. Without committing or even suggesting support for this particular idea, one can imagine a process for marking certain accounts as "public figures" who are not able to deny follows.

[khizka]

I'm not sure the feature is worth the complexity.

Brazilian cluster is requesting this, as it enables harassment or reliving trauma.
It is another tool to control our social media experience, even if it's all public.
Also, wouldn't that be necessary for private accounts? Most of my friends have a private microblogging account, requesting following is necessary.

#1399 may be a temporary client solution

[skunecuscre1]

At the end of the day, following or not, you can easily view the user's posts.

I think the main purpose of soft-blocking on twitter isn't really about preventing people from seeing your posts but more so about breaking a mutual follow without having to awkwardly @ the person and go "hey can you unfollow me i dont wanna be mutuals with you anymore"

A lot of people on twitter have "soft-block if you unfollow" in their bios or carrds for that reason. I think it'd be nice to be able to do that on bluesky somehow.

[glennschler]

Some option to not allow an account to follow me if they are also following more than Y accounts. For one reason is that an account who is following more than 20,000 seems to be a bot attempting to harvest me.

[mschwendener]

Some option to not allow [bot] account[s] to follow me

Agree bluesky-social/social-app#1161

[mschwendener]

confusing for users

For me as a user, they are two separate features that don't have to be tied together.

The option to remove a follower.

I don't mind that they see my posts (otherwise I would block them), but I don't want them to be part of my follower list (and count) – for whatever reason.

(#1160)

The option to have to approve follower requests.

I don't think it would be confusing. It would be a setting in my preferences, and it would work like facebook's friend requests (with the difference that I wouldn't automatically follow them back), the options would be accept/ignore/block.
It would also be close to like DMs were in twitter at the end: you could decide yourself if you wanted to allow everybody to DM you or not.

If users can make it possible to require approval for followers - it would make it feel like a private network
while their data is actually still public.

In my opinion, that would not be confusing. If I don't want my posts to be public, I'll make my account private (#1155 ) - where you'll need some sort of approval mechanism anyway.

---

PS: I like how you phrase it in the blog: "our overall design philosophy: give users sensible defaults but leave them the option to fully customize their experience if they don’t like our choices."

[mschwendener]

2. The option to have to approve follower requests.

Sadly, this seems to be needed https://bsky.app/profile/carlbergstrom.com/post/3k5hwytzr762g

[GlitchyPSIX]

i wonder. usually softblockings are not something that's permanent, some don't mind being refollowed (cleanup reasons?) so how would record publish/depub automation work? i'm assuming appview magic, but that kind of turns these kinds of record into some kind of transient state keeping
for regular blocking I would say that a deny-follow record definitely makes sense to remove a user from the graph