XSF Discussion - 2024-01-16


  1. hyol

    MUC PMs don't support E2EE, do they?

  2. hyol

    I don't really see the point of them. What's wrong with letting users expose their JID?

  3. hyol

    I.e. so they can be messaged normally.

  4. singpolyma

    That is probably the main thing the muc pm protocol is good for

  5. singpolyma

    I mean, I prefer non-anonymous rooms, but we have some cultural history around semi-anon and that's fine and for such rooms one needs something like MUC pm to facilitate decloaking

  6. hyol

    "Anonymous" meaning usernames without JID?

  7. SavagePeanut

    Correct. We call it semi or pseudo anonymous because moderators can see the full jid

  8. hyol

    I think keys should be pinned as early as possible so I would prefer it if they were always visible to the client even if JIDs aren't for whatever reason.

  9. hyol

    SavagePeanut: I see

  10. latex

    Semi-anonymous MUCs delay or eliminate spammers blasting your JID

  11. latex

    Because I feel like anti-spam measures on XMPP are currently insufficient. At least server software doesn't have enough anti-spam settings or modules

  12. latex

    Privacy lists could be helpful, but some people think privacy lists shall perish once and for all, although I think it's a cool thing.

  13. latex

    Privacy lists could be helpful, but some people think privacy lists shall perish once and for all, although I think it's a cool feature.

  14. latex

    But there exists a spammer using a Profanity user agent that can automatically sign up random accounts and spam MUCs, and potentially users too

  15. latex

    But most MUCs being semi-anonymous avoid such situation

  16. singpolyma

    latex: we still have blocking command which is the same function as privacy lists

  17. Zash

    a subset* :)

  18. singpolyma

    I've had a public jid for well over a decade. I do get spam but it's not too hard to mitigate most of it

  19. latex

    > latex: we still have blocking command which is the same function as privacy lists But you can't block entire servers

  20. latex

    Note that this Profanity spammer can create new JIDs on the fly

  21. Zash

    Why do you think you can't block entire servers?

  22. singpolyma

    >> latex: we still have blocking command which is the same function as privacy lists > But you can't block entire servers Yes you can. Many clients even have an easy button for it

  23. singpolyma

    I almost never block whole servers, on principle, but if you want to you surely can

  24. singpolyma

    I would like to see more services implement basic content filtering or even maybe some customizable content filtering. I use this a lot but because I self host it's easy

  25. hyol

    What's a privacy list?

  26. hyol

    > Semi-anonymous MUCs delay or eliminate spammers blasting your JID I guess so. Personally, I've never had a problem with spam on XMPP, but maybe that's because of the measures. I think users should be able to optionally have their JID public. Is that already possible? I haven't noticed an option in Conversations.

  27. singpolyma

    hyol: you mean single users in a semi anon MUC opt to have public jid in that MUC?

  28. hyol

    For example, yes.

  29. Zash

    Privacy Lists is https://xmpp.org/extensions/xep-0016.html - a kind of overly flexible firewall thing.

  30. hyol

    Or the switch could be across all MUCs.

  31. hyol

    But granularity is always good.

  32. hyol

    > Privacy Lists is https://xmpp.org/extensions/xep-0016.html - a kind of overly flexible firewall thing. That's cool. I've always wanted something like that for ActivityPub/fediverse.

  33. latex

    I like flexibility

  34. latex

    But I didn't know you can block entire servers using the block command

  35. latex

    What can privacy lists do that the block command cannot?

  36. Zash

    The one proper use case that's still not covered is blocking everyone by default (aka block strangers)

  37. Zash

    But the protocol itself.. lots of things. Blocking presence but not messages and vice versa. Rules per roster group. Rules per client.

  38. Zash

    Given that the expectation today is that all messages show up at every client, much of that seems unwarranted.

  39. Zash

    Stuff like blocking your collegues during working hours is probably better solved by having different accounts

  40. Zash

    I don't think I ever actually used privacy lists myself. I do remember it had quite the performance impact in Prosody.

  41. latex

    Huh

  42. Zash

    Hah, so XEP-0016 was deprecated twice?

  43. Zash

    https://web.archive.org/web/20210514125140/http://mail.jabber.org/pipermail/standards/2015-September/thread.html#30388 https://web.archive.org/web/20210513194406/http://mail.jabber.org/pipermail/standards/2015-October/thread.html#30415

  44. Zash

    https://web.archive.org/web/20210620165027/https://mail.jabber.org/pipermail/standards/2015-October/030436.html

  45. hii

    yo

  46. hyol

    > What can privacy lists do that the block command cannot? Can they block everyone from a certain server except for a few good users? Because I have always wanted that feature for the fediverse. I've never tried Movim before but it looks cool. Does Movim support XEP-0016? Might be handy for IM use cases as well as social media ones but I personally haven't had a problem yet.

  47. hyol

    A shame it was deprecated.

  48. hyol

    Are there any servers or clients that support it anyway?

  49. singpolyma

    Hmm. It would be nice if blocking a server at least still allowed messages from roster items through. I don't know if any implementation does that right now or not

  50. singpolyma

    Not that I suggest blocking whole servers unless they are confirmed spam farms with no human users of course

  51. MattJ

    singpolyma [20:56]: > Hmm. It would be nice if blocking a server at least still allowed messages from roster items through. I don't know if any implementation does that right now or not I think that would be a good thing to do, and maybe add a note/suggestion to the XEP