Some thoughts on adding Ignore (mute) controls to Superblock?

2026-07-17 14:24:50

adminsforum@hubzilla.org

Harald Eilertsen wrote the following post Fri, 17 Jul 2026 14:24:12 +0200

Some thoughts on adding Ignore (mute) controls to Superblock?

As a discussion has already started in another thread, I thought I'd start a separate thread for this topic. I'm interested in feedback and thought from the community, and also from @Mario Vavti who knows the code and it's history better than most.

As part of my work on improving the Superblock addon one of the issues has been to add more detailed options for blocking, but also ignoring channels. The blocking part of that is implemented in the new Superblock v3.1 that is now in dev, and will be released with the next Hubzilla release.

However, I'd like some feedback on how to deal with the ignore part of that issue.

Currently Hubzilla core supports both blocking and ignoring other channels, but only channels you are already connected to. That is, you can always add a connection and set it to blocked right away, but this feels a bit backwards. The main reason for Superblock to exist is that you can block channels you're not connected to.

However, there are some differences:

Blocking a channel in your contacts blocks any communication with this channel. Superblock will only prevent you from seeing content from blocked channel, but will not (for now at least) prevent your post, likes or other activities from being sent to the blocked channel.
Ignoring a channel in your contacts, does not block communication with the channel, but will block posts and direct replies to your posts from the ignored channel. Your posts, likes etc will still be visible to the Ignored channel. Also afaict responses from the ignored channel to other channels that appear in your stream will not be blocked.
Superblock will technically (for now) not actually block content coming from other channels, only prevent you from seeing it. If you remove a channel from the blocked channel list, the posts from the channel that were posted while it was blocked is now visible again. (This is scheduled to be improved in version 3.2.)

From the above, I think Superblock appears more closely to resemble the ignore functionality provided by Hubzilla core, only that it's a bit more thorough, and works with unconnected channels. Iow, do we need separate functionality for ignoring unconnected channels as well, or is this mainly a naming issue? Does a separate ignore feature even make sense for unconnected channels?

That said, I think the user stories around blocking, ignoring and filtering other channels is a bit fragmented. I have been thinking that it could make sense to collect all of that functionality in one place. And in my view I think having this as an addon is a better option than moving everything to core. The main reason is that it opens for alternatives, so that hubs and channels can chose which implementations suit their needs the best.

Alright. This already got way longer than I thought, but I hope this can make a good start for a discussion of how to proceed with this.

Thanks!

2026-07-17 18:12:08

Mario Vavti

mario@hub.somaton.com

@Hubzilla Support Forum i would not mind to collect all the muting, ignoring and blocking in superblock and removing it from the contact interaction (or at least use the same backend). Not sure how well the addon will integrate with core. The current core ignore and block state is stored in abook. This data is usually already there for various other reasons. It can obviously only be used for connections. Superblock uses pconfig IIRC. Maybe those can be combined in the superblock frontend?

I can imagine some sort of soft ignore (current superblock behaviour) and hard ignore (current contact ignore behaviour) and block (current contact block behaviour). Not sure what mute could be in this context. Maybe the current superblock behaviour could be named mute?

2026-07-17 19:20:40

Der Pepe (Hubzilla) ⁂

pepecyb@hub.hubzilla.hu

@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…

2026-07-17 21:15:57

*_jߍyrope

jrp@hub.kliklak.net

@Der Pepe (Hubzilla) ⁂ Oh so Superblock should be called Supermute, right? In a way a Supermute is exactly what I am looking for, and it would be supercool, if it already were there! @Harald Eilertsen

2026-07-17 21:26:16

Harald Eilertsen

harald@hub.volse.no

@*_jߍyrope There's probably some subleties that need to be ironed out, but from my understanding it more or less is.

2026-07-17 21:38:06

Der Pepe (Hubzilla) ⁂

pepecyb@hub.hubzilla.hu

@*_jߍyrope

should be called Supermute, right?

No, Supermute only works for existing connections (which isn’t what it’s designed for). It blocks external channels (I tried it out today).

A mute function for external channels would probably need to be implemented separately.

2026-07-17 21:48:15

*_jߍyrope

jrp@hub.kliklak.net

@Der Pepe (Hubzilla) ⁂ Didn't you say above

"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." ?

I guess it is more complicated, than necessary ;)

To me, a block is a block. That means i don't see their content, and they don't see mine.

Whereas a mute would let them see my posts and eventually even let them like & comment, however i wouldn't see any of their posts.

I can't imagine a use case for any further mixing of these two ideas.

What do you think?
@Harald Eilertsen

2026-07-18 11:43:26

Harald Eilertsen

harald@hub.volse.no

@Der Pepe (Hubzilla) ⁂

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.

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.