XSF Discussion - 2023-08-14

Hello, I encountered the following behavior while using a combination of prosody and Conversations / Gajim: If I block a participant from a semi-anonymous MUC (by adding room@muc-component.domain.tld/offensive_user to my account's blocklist), their messages are blocked. But they get through when querying the mam archive. If I block a contact based on their jid, and they are in a group chat with me (the kind of group chat where jid's are known), then their messages aren't blocked at all Should the spec be updated to address these things? And are they related to the client or the server? If I had to guess I'd say the first is a client issue and the second is a server one. am I right?

blocking is not really thought trough in MUCs, thats why the spec does not mention it, thats why Gajim at least in current version gives you no option to block a user in a MUC.

i would not suggest to do it manually, you need to undersand the MUC protocol and XMPP in general really good to understand the consequences

and no with the current spec blocking happens on the server, so clients cant do something wrong here

A client could manually apply the block list to mam results

Not necessarily saying _should_ but it could

Seems like it definitely should, no?

Well, or I guess the server should, interesting

The muc server doesn't have your block list

yeah, mam queries where you expect a message, and suddenly nothing arrives without any explanation is a great idea

And for your home server to do dpi that's weird

if i would implement a ignore functionality for MUCs, i would do it also only client side

what you really want is only ignore messages, but if you block on the server level, you block also presence

Do other chat apps allow blocking someone in group chats?

I feel like generally that's a bit of a weird concept

IRC had this

I mean 1:1 obviously. That's pretty straight forward

blocking is the wrong word for me, Ignore is better to convey what is a good functionality

Ignoring is a thing in many clients, but even that is often awkward anyway

ignore conveys, that someone is still in the room, that your client just hides the message

and that is also the most i would do, everything server side i feel has more drawbacks

I don't know how it's implemented in all clients, but I'd assume ignoring doesn't block MUC-PMs often

> but if you block on the server level, you block also presence Actually in the second case (private group chat with known jid's; jid added to blocklist), I still got typing notifications and the blocked contact got my read receipts

That's messages

Still weird though

lissine, thats exactly the issue with MUC, block happens only on *your* server, but you send messages not to contacts, you send it to the MUC, and the MUC sends it further

so if you block someone in a MUC, its only one way, he will receive all your messages

Yea /ignore is one of the best features of IRC honestly

its stuff like that why Gajim does not allow blocking in MUCs, because its hard to tell the user what that actually means

Easier when only 1 server and client involved of course :)

/ignore is awkward. To me the best feature is to talk about it in the concerned community :x

personally i never had the urge to block someone, since IRC days

and back then it was always my brother if he triggert me :D

I've been in IRC channels where certain people just always had to /ignore each other to avoid fighting constantly

You don't solve problems by ignoring them though

some problems dont need solving

It makes for some interesting conversations too "what are you talking about?" "Oh you are talking to X huh?" 🤣

or not talking to each other is the solution

i also have to say its rare that some user wants that feature in Gajim

I guess this would be nicest as a MUC extension that remembered your ignore list by JID ?

like its not even in the top 10 of things

Maybe you just aren't in MUCs where there are a lot of people worth ignoring, would you like an invite? :P

One could have an ignore/block list using occupant-id or sth nowadays

pep.: occupant-id would be what you want if you did it client-side, if the muc server did it, it could just filter by JID?

But users may not know JIDs

MUC can do whatever it wants surely

Doesn't need to, I can tell the muc to ignore the nick 'bob' and it'll add the jid currently connected as 'bob' to the list?

It should, if bob doesn't /part right before you send the command

Yes... Maybe that's ok though

That's an easy enough papercut to solve.. by not using nicks

Muc rooms aren't necessarily remembering occupant-id's after disconnect either though

No but the id is stable so it'll be the same next time that user rejoins

? that would be a very bad implementation moparisthebest

I recall the discussion about reproducibly generating them so they didn't need stored ?

Well the MUC would still store the blocklisted ids

Ah gotcha, yep that'd work

And then a mod could put 2 people on each other's ignore list, I've always missed that ability in IRC :D

Yeah I don't know if I want moderators chiming into my ignore/block list

Moderators already have control over the outcast affiliations

> Do other chat apps allow blocking someone in group chats? Discord, at least.

I've definitely needed 2 people to ignore each other at least temporarily in a channel

When I first learned you could block MUC participants, I assumed it would just prevent you from receiving their MUC PMs. Maybe it would be best that way, with the ignoring in a separate extension

Sounds like with the mam hole that's effectively what it does

the blocklist doesn't change mam results

I agree that having the MUC store your ignores feels wrong and it's probably got to be client side

I'm not sure I'd want someone I blocked auto ignored in MUC, but a way to ignore them I've heard from a few people wanting it

I'm abusing the blocklist for some bots, I'm in st least three mucs/irc rooms that all announce fdroid updates. And I want zero. If the client would also not show it in mam, it would be already great.

> I agree that having the MUC store your ignores feels wrong and it's probably got to be client side Then you need a way to sync it across all your clients, which is maybe more annoying? I'm not seeing a clear winner here though, just pros and cons to both ways ↺

We already have a standard system to sync arbitrary stuff across clients though (pep)

So I think the list is something like this, please correct me: Implement blocking in the client: 1. Server must implement occupant-id 2. Each and every client would need to implement it, as well as sync'ing with pep 3. "Wasted" bandwidth/battery because the filtering happens on the device Implement blocking in the muc service: 1. Server must implement occupant-id 2. Server must implement this list handling and filtering 3. Clients don't even get messages they didn't want, no battery/bandwidth impact 4. It would apply even for clients without support for modifying the ignore list, so ie you ignore in Conversations, messages stop coming in Dino and jabber.el too

I don't see a clear winner, first is nicer if you don't control the server and only use clients that will implement it, second is nicer if your server will implement it but only one of your clients will Maybe we need both? 😭

Client needs to get some message in either case IMO so it has the option to show a tombstone

If so that's a nail in the coffin for the server side impl, I personally would not want any indication they sent a message, but maybe others do?

> Stickers are already supported (XEP-0449), but client support is limited for now oh cool one of my friends was wondering about that since they came from telegram