@Hubzilla Support Forum
I’ve been experimenting a bit again and have come to the following conclusions:
1. Superblock and connection blocking are independent of one another.
2. If I set a Superblock on a connection, posts from that connection are no longer displayed in my stream. However, the Superblocked connection can still see my posts, including any subsequent ones.
3. If I set a connection block (i.e. in the app ‘Connections’ section) on a connection, I will no longer see posts from that connection. However, from that point on, the connection will also no longer receive any posts from me.
4. If I set a superblock on a third-party channel (which is not a connection), I no longer see its posts, but it also no longer receives my subsequent posts.
This is entirely logical. We really must first consider the two mechanisms independently of one another (as mentioned in 1). It actually makes no sense to superblock an existing connection.
To genuinely block a connection, you must, of course, use the connection block. If, on the other hand, you use the superblock, it behaves like ‘muting’: we don’t see what they post, but they see everything we post.
With external channels (no connection), the superblock therefore works as expected. With channels from your own connections, however, it does not. In that case, it acts like a ‘Mute’.
From a UX perspective, I would suggest that when Superblock is applied to an existing connection, it should simultaneously trigger a connection block. However, removing the user from the Superblock list would then also have to reverse the connection block. This would be a behaviour that would make sense even to users who aren’t experts.
Or… if it’s simpler to implement, Superblock shouldn’t display the “Block completely” menu option (for the Superblock) for existing connections in the first place, so that the user is forced to set the block in the connection editor.
Just my two cents…
I’ve been experimenting a bit again and have come to the following conclusions:
1. Superblock and connection blocking are independent of one another.
2. If I set a Superblock on a connection, posts from that connection are no longer displayed in my stream. However, the Superblocked connection can still see my posts, including any subsequent ones.
3. If I set a connection block (i.e. in the app ‘Connections’ section) on a connection, I will no longer see posts from that connection. However, from that point on, the connection will also no longer receive any posts from me.
4. If I set a superblock on a third-party channel (which is not a connection), I no longer see its posts, but it also no longer receives my subsequent posts.
This is entirely logical. We really must first consider the two mechanisms independently of one another (as mentioned in 1). It actually makes no sense to superblock an existing connection.
To genuinely block a connection, you must, of course, use the connection block. If, on the other hand, you use the superblock, it behaves like ‘muting’: we don’t see what they post, but they see everything we post.
With external channels (no connection), the superblock therefore works as expected. With channels from your own connections, however, it does not. In that case, it acts like a ‘Mute’.
From a UX perspective, I would suggest that when Superblock is applied to an existing connection, it should simultaneously trigger a connection block. However, removing the user from the Superblock list would then also have to reverse the connection block. This would be a behaviour that would make sense even to users who aren’t experts.
Or… if it’s simpler to implement, Superblock shouldn’t display the “Block completely” menu option (for the Superblock) for existing connections in the first place, so that the user is forced to set the block in the connection editor.
Just my two cents…
How is this different from when the third-party channel is not blocked by Superblock? They will still not receive your content.
In both cases they may still see your content if your post is public, and somebody else on their hub/instance is connected with you, or when you interact with a post from someone they are connected to.
Superblock should afaict not interfere in any of those scenarios.