jdev - 2025-02-08

is there really not "muting by occupant-id" xep yet? i figure more than just cheogram should be doing this

What would the xep be? An extension element for bookmarks2 to sync mutes I guess?

essentially yes

There are very few MUCs I find this useful in. Basically just in wild unmoderated spaces. But still it can be useful, that's probably a xep that would be easy to write

(that or this should be done serverside)

I'd certainly rather not do this kind of thing serverside, especially since the UX would necessarily be different

I ask purely out of feeling like I want that on desktop (gajim) too, where blocking (171) is too heavy a hammer, but it seems like a weird thing to implement on two different places in different ways with no way to keep them in sync

are we talking about muting or client-side ignoring?

in the context of cheogram, those are the same thing. on clientside, it mutes those who are listed, with UX such that their messages appear by name, but the content is replaced with "Muted", and contiguous messages are collapsed ✏

mathieui, was asking if you want that a MUC moderator can mute a person

but the answer is No, you talk about client side ignoring

i thought about implementing this in Gajim multiple times

but there are many questions on how this should work in the client exactly

do i still store the message, and just dont display it, does the user later want to unignore and want to read the messages?

or do i simply drop all data and replace with a dummy text

do i replace every message with some dummy text like "You ignored this user"?

but is this not silly then if you have a chat full of these messages?

because this user had a conversation

Presumably that conversation is the reason for muting them

Cheogram takes the discord system. the mute is ui-side, and unmuting shows the messages, which is useful if you need. As discord as discord is, that ux is pretty clean.

the question is, do we expect that if i mute a user, that their messages take less space in the chat?

I'd keep the messages, but don't present them, and then the can be reshown if unmuted again ✏

I'd keep the messages, but don't present them, and then they can be reshown if unmuted again ✏

Hmmmm, `.muted { font-size: xx-small }`

I think that would be a client ui choice. Collapsing consequent ones makes sense, but it doesnt matter, if it's real bad, there's moderation or blocklists

all of this is a client side UI issue, if you exclude syncing a list of strings to pubsub, which is a trivial thing

If their messages are displayed as "Muted" then they take less space than the possibly multiple lines otherwise; merging consecutive muted messages is also an option

Could treat them as status messages, if those are even still shown. "a muted user said something"

Or even just a header line (no content), with the option to click/press to view/rehide

Something like content warnings/spoiler messages?

That would likely have a placeholder for the content; this is without - simply name+time

Maybe with an indication that it's muted, e.g. LoudMouth 12:34:56 [muted]

The collapsing multiple subsequent, both for muting and moderation, is excellent

Yep that's what cheogram shows, and if he posts 30 more times you still just see the 1

wait, xmpp doesn't have an equivalent to IRC's +q <mask>?

("quiet". it's like a ban but the user can still receive messages, just not send or change nick)

Most servers don't implement an exact equivalent