pepecyb@hub.hubzilla.hu

@Harald Eilertsen

Personally, I don’t need a mute function that brings back the posts that were previously hidden once the mute is lifted.

It doesn’t really seem necessary either, because when you mute something, you do so for good reasons… you don’t want to see those posts. If you lift the mute, most users will simply assume that applies going forward.

Ultimately, therefore, an ‘Ignore’ and a ‘Block’ option would be entirely sufficient, provided they can also be applied to third-party channels and the lists can be managed via the add-on.

@Mario Vavti

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

Perhaps, however, when it concerns connections, the menu could be expanded to include ‘Ignore’ and ‘Block’ to avoid having to go via the ‘Edit connection’ editor (although I don’t actually find that route particularly cumbersome).

@Harald Eilertsen

@*_jߍyrope

That’s exactly what I wrote. A superblock is a ‘supermute’ when applied to connections. But a Superblock is a ‘Superblock’ when applied to external channels. That’s why it would make sense not to display the Superblock menu item in Connections, or to extend Superblock so that, when applied to Connections, it also blocks or unblocks those channels within the Connections.

As it stands, it’s a bit confusing for the user, although I myself would never think of blocking a connection with Superblock, as that’s precisely what the function in the ‘Connections’ section is for. In my view, the most sensible approach would be to hide the Superblock menu item for channels you’re connected to. After all, Superblock exists precisely so that you can block third-party channels (with which you have no connection), which isn’t possible with the connection block. I don’t think implementing the menu suppression would be too complicated either.

@Harald Eilertsen

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

@Hubzilla Support Forum

Block blocks the connection in both directions. The contact will no longer receive your posts, and you will no longer receive theirs.

Ignore is similar to ‘mute’ on other services. Whilst you will no longer receive their posts, they can still receive yours.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

I’ve just been looking into this topic in more detail, particularly in relation to Mastodon.

When you attach an image with a caption on Mastodon, both the `alt` and `title` attributes are set to that text. This means that when the image is imported into Hubzilla, the text description is also displayed as a title pop-up.

If you add a description to an image on Hubzilla by placing it between the [zmg][/zmg] tags (the usual method), i.e.

[zmg=<IMAGE_URL>]<IMAGE_DESCRIPTION[/zmg]

Hubzilla behaves in exactly the same way as Mastodon, inserting the description using both the alt attribute AND the title attribute.

When this reaches Mastodon, the image description is also flagged and displayed accordingly.

If, on Hubzilla, you insert the image description within the [zmg=] tag, the image description is added as the alt attribute, but no pop-up appears because the title attribute is not set. On the receiving end, e.g. on Mastodon, the alt text is flagged and displayed.

So, if you want an image description on Hubzilla not only to be present but also to be visible as a pop-up, the “usual method” is the better choice. If it’s really just about the image description and you don’t want a huge pop-up to appear for “epic image descriptions”, then use the option with the alt attribute within the [zmg=] tag.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

I’ve just had a look at the source code of my test posts. AND: Yes, the `alt` attribute does what it’s supposed to do and inserts the `alt` attribute correctly into the HTML.
It was simply a misunderstanding.

@Harald Eilertsen @𝓒𝓱𝓻𝓲𝓼

Ah, OK... we’re using different terms here.

You mean the actual HTML ‘alt’ attribute, which contains text that is displayed if the actual image cannot be shown. I think you can set it correctly using ‘alt=’ in Hubzilla. So it will work after all.

However, by “alttext” we actually mean this pop-up text, because that’s what’s now commonly used in everyday language for image descriptions. And for that, “alt” doesn’t work – only “title” does.

A communication problem due to differing definitions.

It really would be better not to write or say “alttext” for image descriptions, but to actually use “image description”.

Have a look online: there are now quite a few “alt-text bots” that are actually “image description bots”.

@Harald Eilertsen I’ve just finished a test session… with ‘x’ variations.
Based on my tests, I’ve found that the ‘alt’ attribute has no effect whatsoever, at least on my hubs.
The ‘title’ attribute must be used as the alt text. That way, it works.

@citc I’ve tried it (on two different hubs, both running 11.2.1). I haven’t been able to reproduce the problem so far.

Perhaps someone else is experiencing the same issue. I’m afraid I can’t be of any further help.

@Hubzilla Support Forum @citc

What do you mean by ‘share’?

Did you want to share a public post from Channel Y's stream to Forum X?

That works (just tested it).

“Sharing” as ‘posting’ also works with Wall-to-Wall, Privacy Tool and @! mentions.

@KlausR Ah, OK. So the problem was that the poll was sent to a specific privacy group (i.e. to the connections within that group).

By design, that doesn’t work either, as a guest account doesn’t have its own stream.

Question for @Mario Vavti  : Which permission actually applies to polls? I think it should be ‘Can comment on or like my posts’, correct?

@Ema エマ Yes, it needs to be written in.

@Hubzilla Support Forum @KlausR

By ‘group’, do you mean a forum channel?

I’ve just tried it out using one of those, and it really isn’t possible to take part in a poll like that with a guest access token (posting comments, on the other hand, works).

I’m not sure, though, where you’d need to go to enable guest access to polls separately.

There is no separate permission for this in the roles.

For the test guest access, I created a ‘Standard-Plus’ contact role that allows everything except uploading to the cloud, editing wikis and web pages, and administration. Even with this contact role assigned, the guest was unable to take part in a poll.