XSF Discussion - 2023-08-14

  1. lissine

    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?

  2. lovetox

    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.

  3. lovetox

    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

  4. lovetox

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

  5. Daniel

    A client could manually apply the block list to mam results

  6. Daniel

    Not necessarily saying _should_ but it could

  7. moparisthebest

    Seems like it definitely should, no?

  8. moparisthebest

    Well, or I guess the server should, interesting

  9. Daniel

    The muc server doesn't have your block list

  10. lovetox

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

  11. Daniel

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

  12. lovetox

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

  13. lovetox

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

  14. Daniel

    Do other chat apps allow blocking someone in group chats?

  15. Daniel

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

  16. lovetox

    IRC had this

  17. Daniel

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

  18. lovetox

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

  19. pep.

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

  20. lovetox

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

  21. lovetox

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

  22. pep.

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

  23. lissine

    > 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

  24. pep.

    That's messages

  25. pep.

    Still weird though

  26. lovetox

    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

  27. lovetox

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

  28. moparisthebest

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

  29. lovetox

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

  30. moparisthebest

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

  31. pep.

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

  32. lovetox

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

  33. lovetox

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

  34. moparisthebest

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

  35. pep.

    You don't solve problems by ignoring them though

  36. lovetox

    some problems dont need solving

  37. moparisthebest

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

  38. lovetox

    or not talking to each other is the solution

  39. lovetox

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

  40. moparisthebest

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

  41. lovetox

    like its not even in the top 10 of things

  42. moparisthebest

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

  43. pep.

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

  44. moparisthebest

    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?

  45. pep.

    But users may not know JIDs

  46. pep.

    MUC can do whatever it wants surely

  47. moparisthebest

    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?

  48. pep.

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

  49. moparisthebest

    Yes... Maybe that's ok though

  50. pep.

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

  51. moparisthebest

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

  52. pep.

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

  53. lovetox

    ? that would be a very bad implementation moparisthebest

  54. moparisthebest

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

  55. pep.

    Well the MUC would still store the blocklisted ids

  56. moparisthebest

    Ah gotcha, yep that'd work

  57. moparisthebest

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

  58. pep.

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

  59. pep.

    Moderators already have control over the outcast affiliations

  60. Kev

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

  61. moparisthebest

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

  62. lissine

    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

  63. singpolyma

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

  64. lissine

    the blocklist doesn't change mam results

  65. singpolyma

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

  66. singpolyma

    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

  67. Menel

    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.

  68. moparisthebest

    > 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

  69. singpolyma

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

  70. moparisthebest

    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

  71. moparisthebest

    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? 😭

  72. singpolyma

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

  73. moparisthebest

    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?

  74. opal

    > 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