harald@hub.volse.no

I think the idea is cool! The data should already be available via the Hubzilla API, so it should be possible to do this without any significant extra work on the server side.

@Beni Grind ~HB9HNT To not have written PHP for 20 years, I find it fascinating that you use constructs introduced in PHP v8.0 :)

I think it looks good in general. A few nitpicks, but nothing major. I leave the final judgement to Mario :)

@Beni Grind ~HB9HNT

I should rather fix this and make Hubzilla more IPv6 capable.

That would be great! Ideally it should not have to care which protocol version it's using, but that would mean getting rid of implicit assumptions that are only valid on IPv4.

@Der Pepe (Hubzilla) ⁂

In that case, it would make sense to rename the add-on to ‘Supermute’ and change the menu option to ‘Mute from channel’.

How about just "Mute"?

Adding "Ignore" and "Block" to the menu items of connected channels is trivial. Adding the same expiration feature that Superblock now has is also doable. If we move all this functionality to Superblock, it would almost come by itself. (I think...)

The question is: Do we really need all three options? "Mute", "Ignore" and "Block"? Or would it be enough with just "Ignore" and "Block"?

Do we really want that posts and interactions posted while "muted" should reappear when the mute expires?

@*_jߍyrope

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'm open to change how we name things if that can make it less confusing. Exactly what the names will be is less important as long as we agree on, and can describe how the different features work and fit together :)

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

@Mario Vavti

I can imagine some sort of soft ignore (current superblock behaviour) and hard ignore (current contact ignore behaviour)

That's an interesting option.

As mentioned earlier, my current plans for the next Superblock version is to block incoming activities, so that they will no longer become visible again when the block expire or is removed.

From your feedback here it seems we should think more closely about this before going that direction.

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

@Jupiter Rowland It could also be that the jsonld library we're using us not up to date with the latest standards. JSON-LD is quite cool when used to it's fullest, but it's also a pretty hairy standard to parse.

Knowing where these payloads come from may help debug the issue, but not sure if it's worth it if it's only from this site and it's using unstable software.

@Alfred Bühler

First off, blocking infoseek.exchange under admin->security didn't seem to work. I had to block it via the .htaccess file. Then I recognized the trailing '/' as part of the host name! Adding this, Hubzilla's blocking works;

That seems like a bug to me. We should be able to match against only the domain name.

BTW, I apologize for the double post. Obviously my subscription to this channel is broken. I no longer see any forum posts in my stream.

I had that happen to me to at some point. I think somebody with admin rights to this channel needs to go in and see if you're marked as unreachable or something.

@Poul Udbye Pock-Steen Ok, I have not looked into the attachment name yet. I'll see if I get time tomorrow.

I've made a merge request that I think will fix this issue here:
#^https://framagit.org/hubzilla/core/-/merge_requests/2301

@Poul Udbye Pock-Steen Ai, that's not good... I'll have a look.

@Der Pepe (Hubzilla) ⁂ Terms can be confusing, but the two attributes have different meaning for a reason.

The alt attribute is the one being used by screen readers to provide image descriptions to blind or visually impaired people.

The title attribute however is a global attribute meant to provide additional info about whatever element it's attached to. This is typically shown as a tooltip when hovering over the element.

Most screen readers will fall back to the title if the alt attribute is not present, but it's not safe to rely on that. The attributes are distinct and has a different purpose for a reason.

@Der Pepe (Hubzilla) ⁂ are you sure about that?

The example from @𝓒𝓱𝓻𝓲𝓼 above does not set the correct html alt attribute:

<img class="zrl" loading="eager" style="width: 100px; height: 200px; max-width: 100%; cursor: zoom-in;" alt="Bilde/fotografi" title="Alt Text" src="https://klacker.org/photo/cd747cd9-3f05-42cd-94cc-91c7368c5a18-2.png">

Don't confuse the alt attribute with the title which is the one that pops up when you hover over the image.

@Poul Udbye Pock-Steen In which text field do you observe this behaviour?

To actually get an alt attribute in the generated html, use something like [zmg ... alt="a bleak outlook over a nascent moon"]

There's a few other attributes supported as well. Here's a complete list:

• alt="Alt text"
• title="A title"
• width="42" with in px.
• height="66" height in px.
• class="myclass otherclass" custom CSS classes.

In addition there's a legacy format still supported:

[zmg=42x66 float=left alt=some alt text at end]

Note that the order of the attributes must be exactly like this in the legacy format. Both the float and alt attributes are optional, but must come in this order if present.

Note also that the float attribute is not directly supported in the new format, but can be simulated by setting a CSS class instead.

I think we should probably add back the float attribute directly in the new format as well.