Zum Inhalt der Seite gehen


Block feature behavior informal poll


Hi !Friendica Support,

to settle a technical disagreement in this GitHub issue (not required to read), I would like to know what you expect on any social media platform when you unblock someone. If you were following them and them following you before you blocked them, you expect:

  1. Both follow directions to resume working automatically.
  2. Them to still follow you but you have to re-follow them manually.
  3. You to still follow them but they have to re-follow you manually.
  4. Both of you to have to re-follow each other manually.
  5. Other? Please describe your expectations.


Thank you in advance for your participation!

teilten dies erneut

Als Antwort auf Hypolite Petovan

@Hypolite Petovan @Steffen K9 🍮 I *expect* all communications to be severed and everyone has to follow again (#4), but not because it *ought* to be that way, but merely because other systems behave that way and because my mental model of the most likely implementation works that way.

Do, undo, return to original state (#1) is the *better* behavior and it's the intuitive one for anyone not trained on other systems or thinking like a programmer.

Als Antwort auf Hypolite Petovan

1. Both follow directions to resume working automatically.

Rational: Blocking might have be done for "temporary pausing", accidentally, or whatever. Having to reset the following relationship mode would be seem counter-intuitive.

Als Antwort auf Hypolite Petovan

@mʕ•ﻌ•ʔm jeSuisatire bitPickup [italic~irony] .. ᘛ⁐̤ᕐᐷ Doesn't imply that the other person would know they are blocked, as they find they are not following you any more ?
Als Antwort auf Andy H3

@Andy H3 @mʕ•ﻌ•ʔm jeSuisatire bitPickup [italic~irony] .. ᘛ⁐̤ᕐᐷ Yes, making the other party unfollow you is a privacy leak. So is simply not sending them messages, but less so.

Note that SharedInbox combined with not telling the other server their user is blocked leads to surprising behavior, yet this is what an AP node implemented the correct and most obvious way will do.

I suppose if anyone on a server is blocked by you, your messages shouldn't go to SharedInbox.

Unbekannter Ursprungsbeitrag

Andy H3
accidentally hit the "block" button

Or hit in rage that one regrets a moment later.

Unbekannter Ursprungsbeitrag

hoergen (Ai)

@Michael Vogel the way you are describing it, it is called "mute".
Blocking always ends a relationship on every other social network.
Creating a new definition here leads to further confusion in comparison to all other networks.

@Hypolite Petovan

Unbekannter Ursprungsbeitrag

hoergen (Ai)
ok, I'm just telling tat this confuses people.
Als Antwort auf Hypolite Petovan

@Hypolite Petovan #1, especially since requiring manual re-follow on either side will create confusion. Users will not understand this requirement, so an info dialog would have to be shown and we all know how happy users are to reading such dialogs.
Als Antwort auf Hypolite Petovan

I'm for #1 :
If I have "action" and "unaction", I expect "unaction" to get me back to the status i was before "action": "mute/unmute", "follow/unfollow" "block/unblock", "delete/undelete"...
#1
Als Antwort auf hoergen (Ai)

@hoergen @Michael Vogel @Hypolite Petovan Yes. Soft-blocking (force-unfollow) with a block+unblock is a well-known maneuver, so we probably should accept that we live in a society of pre-existing social networks with certain behaviors.
Als Antwort auf Hypolite Petovan

Thank you all for your input, I personally am agreeing with @hoergen based on the behavior on other social media platforms I've been using (Twitter, Facebook) where blocking cuts all ties, but it seems Friendica users have different expectations. This discrepancy is an issue because by design we expect people from other social media platforms to move to Friendica.

Technically, all the cases are easy to implement, but we will need to explain this discrepancy in the interface and even with a well thought-out pop-up confirmation message, I'm not sure it will be enough to clear all the confusion, especially from people using apps based on the Mastodon API where the expectation is 4.

Als Antwort auf clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

We have plans to add an explicit revoke follow action for networks that support it (like ActivityPub) so it would remove the need for blocking to silently do it.
Als Antwort auf Hypolite Petovan

Forcing someone to unfollow me is a critical feature even if I don't use it much-

This is especially true for accounts with approval where you may just not want someone to see your private posts anymore

It's not just wrong it's noticably broken to do anything but terminate everything

Als Antwort auf Hypolite Petovan

So it seems we are gravitating towards a hybrid solution:
- Friendica frontend will offer the possibility to manually revoke a follow.
- Friendica frontend blocking will not sever the current existing follow relationships.
- Mastodon API endpoint blocking will sever the current existing follow relationships to match Mastodon's behavior.
Als Antwort auf Hypolite Petovan

this means that blocking in web ui and blocking in an app will lead to different results?
Als Antwort auf Fabio

Unfortunately, yes. We have to follow Mastodon’s behavior when using their API, because we have to believe this is what Mastodon clients and their users will expect.

On the Friendica frontend we can (and probably should) follow the results of this informal poll which heavily leans towards 1, even if I’d rather not but I don’t want to alienate the current user base.

Unbekannter Ursprungsbeitrag

Andy H3
we have got "mute" and "block" and both doesn't change something in the relationship.

What does 'mute' do ? Is this a new feature, @Michael Vogel ?

At the moment I can only see 'Block' 'Ignore' 'Delete'.

Als Antwort auf clacke: exhausted pixie dream boy 🇸🇪🇭🇰💙💛

Yes. Soft-blocking (force-unfollow) with a block+unblock is a well-known maneuver, so we probably should accept that we live in a society of pre-existing social networks with certain behaviors.

So does this mean we are a bunch of technical geeks without a clue what happens outside the world of Friendica? :facepalm

Unbekannter Ursprungsbeitrag

Hypolite Petovan
What's the difference between "implementing user-expected behavior" and "copy Mastodon behavior"?
Unbekannter Ursprungsbeitrag

Hypolite Petovan
Of course, but I believe we have to go with the most likely. Mastodon-compatible apps are branded as such so I believe it does set expectations towards Mastodon rather than Friendica.
Unbekannter Ursprungsbeitrag

Hypolite Petovan

It doesn't really matter, we have no control over the messaging inside Mastodon-compatible apps, so we have to go with assumptions about Mastodon behaviors.

On the contrary in the Friendica frontend we have 100% control so we can do anything and inform users as such.

Unbekannter Ursprungsbeitrag

Hypolite Petovan
It doesn't matter for the client itself, but it matters for their users since we can't communicate in the Mastodon-compatible app the Friendica-specific behavior.
Unbekannter Ursprungsbeitrag

Hypolite Petovan
Yes, but they are using their Friendica account through a Mastodon-compatible app that we do not control, so we cannot show a message "your relationship will be kept even if you block" and even if we somehow could, we wouldn't be able to offer the associated "revoke follow" feature that only the block feature can achieve on Mastodon.
Unbekannter Ursprungsbeitrag

Hypolite Petovan
I understand it has the same technical outcome to you, but it's about avoiding the surprise of immediately getting messages from a contact you just unblocked, either in your feed or as a reply to your own posts that would instantly be delivered to them again. This isn't something Mastodon-compatible app users expect, whether their account is hosted on a Friendica node or anything else.
Unbekannter Ursprungsbeitrag

Hypolite Petovan
How could they be sure the Friendica behavior would be enforced since they knowingly use an app made for Mastodon?
Als Antwort auf Hypolite Petovan

I understand that as a Friendica user of 10 years I am in a small minority vs the many current and, hopefully, future users this software attracts, so I can understand that some older behaviors may (have to) change. I suspect that while I and users above do have a certain expectation on the behavior, there may not necessarily be a way to solve this that accommodates both (valid) view points.

I don't know if you have already considered the option to offer two different options to the users, "blocking" (which can be undone) and "block and permanently end relationship"? I'd imagine the argument against it is that it is confusing and/or causes technical complexity (requiring a new type of connection between user and the blocked account to be stored, which also requires a UI to manage these separately from contacts, etc.)

Als Antwort auf elrido

Thank you for your comment. On the technical side, it's trivial to implement either behavior. We are inching towards a two-buttons solution where one button will be used to block a contact, and another will be used to independently revoke a follow for compatible protocols (only Mastodon so far).
Unbekannter Ursprungsbeitrag

Hypolite Petovan

If they were using a specifically Friendica-compatible app, of course, but since we're piggy-backing off of the Mastodon ecosystem, I believe we have to take Mastodon behaviors into account.

Last but not least, many Friendica users (myself included) come from other platforms, whether it is Facebook, Twitter or even... Mastodon possibly. And all of these have in common the same behavior for blocking. So we just can't expect Friendica users to know exactly how blocking works in Friendica since it's different from every other social media platforms. This discrepancy is fine in the Friendica frontend where we can spell the actual behavior for users, but it is different in the Mastodon-compatible (or Twitter-compatible) apps that we can't control.

Unbekannter Ursprungsbeitrag

Hypolite Petovan
I don't think this is sustainable, I'm not sure Friendica users are aware about all the currently available settings, so adding one will not help in that regard. Besides, we're back to square one, what should be the default? Would it apply to both frontend and API?