jdev - 2024-01-07


  1. manday

    Is there a mechanism in XMPP which authorizes a given JID to join a private MUC à priori? Thinking à-priori permissions inherited from LDAP here, e.g. all members of group "abc" are allowed to join the MUC "abc".

  2. jonas’

    manday, you can affiliate JIDs with a MUC without them being present

  3. jonas’

    and any member-affiliated-jid can join a members only MUC

  4. MattJ

    Something like LDAP integration is a matter of implementation rather than protocol

  5. jonas’

    you could write a server plugin which fetches group membership and feeds that into MUC affiliations

  6. jonas’

    yes

  7. manday

    jonas’ will this be consistently retained? I.e. could a permission (to join) realized that way be accidentally revoked/get lost, for example through a user action such as leaving the room (or even explicitly removing themself from a the member list)?

  8. jonas’

    manday, no

  9. jonas’

    you need a certain privilige to change the affiliation list, which a `member` affiliated user doesn't have

  10. jonas’

    so just leaving a MUC won't revoke that permission, and I don't think you can de-afffiliate yourself.

  11. manday

    That sounds like fairly good of a solution then. Thanks. Optimally, the MUC affiliations wouldn't have to be updated in a push/cron'y fashion but there would be a way to have the server look up said affiliations "externally" (LDAP) whenever they are relevant.

  12. jonas’

    as MattJ said, that's an implementation detail more than anything

  13. jonas’

    not a protocol thing

  14. manday

    Yes

  15. manday

    Well, it would touch the protocol in so far as that manual modifications of the member affiliation list would have to be forbidden. But I assume that shouldn't be a problem.

  16. jonas’

    that's also just an implementation :)

  17. jonas’

    servers can return <policy-violation/> or <forbidden/> for anything they want

  18. manday

    Cool :)

  19. MattJ

    FWIW Snikket does basically all this (but not LDAP)

  20. MattJ

    You define a group of user accounts (a "circle") and can create one or more MUCs where the membership is synchronized to the membership of the circle

  21. Guus

    Openfire has the concept of Future Users that comes close to this.

  22. Guus

    Allows for things like offline messages and rosters to be maintained for users that do not exist in the backend user store yet.

  23. manday

    That would be more than needed (although I see that it can be useful)

  24. manday

    Is there any provision in XMPP which allows to keep read-state consistent across devices? The only cross-device semantics I have encountered are bookmarks, as a means to keep joined rooms consistent; is there more?

  25. manday

    I've noticed that the read-state does not seem to be held consistent across movim and monocles/conversations

  26. Zash

    XEP-0333 sorta does that, sometimes

  27. manday

    Hm yeah that's very "sorta" as it seems to require to mark the message in the MUC, visible for all.

  28. manday

    So, bluntly put, I disapprove of delivery receipts and chat markers for privacy reasons, yet I want to my devices to "correctly" display which messages I have not read.

  29. Zash

    As I understand, the Tigase clients send '333 messages to yourself via MUC PM, which is a touch awkward but said to work (unless PMs are disabled).

  30. Zash

    I've not heard any progress on e.g. a PEP based read state thing yet.

  31. MattJ

    It's planned for the Snikket SDK, at least

  32. manday

    Wouldn't it be analogous to "bookmarks"?

  33. Zash

    Hm?

  34. manday

    Okay maybe I should start differently... For multi-device users, bookmarks seem to be "the" way to keep chats consistent across devices, right? I.e. if you want to use multiple devices, all your chats should be bookmarked. Assuming that, every chat could get its respective "read marker" saved in the bookmark.

  35. manday

    Instead of "bookmark" it should probably be called "user chat state" or sth....

  36. Zash

    group rosters!

  37. manday

    well yes that's XEP-0402 aka PEP bookmarks no?

  38. Zash

    Yes, sure.

  39. Zash

    I would think it more efficient to use a separate PEP node, so that clients that do not implement the new read marker don't get updates for them.

  40. manday

    i agree. I was only trying to illustrate that it's a 1-to-1 map to bookmarks

  41. Zash

    Much higher rate of change, you read messages more often than you join or leave chats. Nothing says we can't have multiple parallel things for each chat.

  42. manday

    Ah ok, yah

  43. manday

    I'm confused, is Roster and Bookmarks two separate things? All the specs regarding the one don't mention the other and vice versa?!

  44. Zash

    Roster is only contacts, not group chats. Bookmarks is for group chats only. Both are similar if you squint at them.

  45. pep.

    "I don't think you can de-afffiliate yourself." and even if you could, the MUC in this case could refuse it

  46. pep.

    (Ah you mention it later)

  47. Zash

    (I think you can XEP-77 de-register?)

  48. manday

    Could anyone help me try how well E2EE works? This has been a notorious problem with Matrix (for me) and I would like to see how easily XMPP clients handle it.

  49. manday

    I've enabled OMEMO in both my devices' clients (Monocles and Movim) but it appears I currently have no E2EE chats and there show no options regarding encryption.

  50. manday

    So my first impression with just *me* is unfortunally not positive. I've created a private MUC (on Movim) and messages I write in Movim show well on Monocles, but messages I send in Monocles don't decrypt in Movim.

  51. manday

    I just get a > I sent you an OMEMO encrypted message but your client doesn’t seem to support that. Find more information on https://conversations.im/omemo

  52. MattJ

    If that can be reproduced it sounds like a bug in one of those clients

  53. manday

    Exactly that point has been the crux with Matrix, too. As only a user all we can/could observe that it "didn't work (tm)" but without diagnostics no one ever looked at it because eventually it was a compat problem and neither side felt responsible. (I guess with Matrix it's even worse given how the server is involved in a more complicated fashion).

  54. manday

    Well in this case it looks like Movim is certainly to blame for parts of the issue. I just noticed that the text field has a "lock" button which can be used to activate encryption. After I did that, Movim won't even display the messages it submitted itself 😅

  55. manday

    They do, however, decrypt fine on the Monocles instance

  56. MattJ

    Movim's implementation is much newer than the one in Monocles, so it's very possible bugs could still exist in places. Submit a bug report?

  57. manday

    I will

  58. MattJ

    Thanks ❤️

  59. manday

    Looks like someone beat me to it: https://github.com/movim/movim/issues/1261

  60. manday

    I'll browse the issues and see whether it's mine.

  61. wgreenhouse

    > Could anyone help me try how well E2EE works? This has been a notorious problem with Matrix (for me) and I would like to see how easily XMPP clients handle it. manday: I use conversations/cheogram and poezio, those are reliable for me in omemo. movim's e2ee implementation is newer, and made more complex by the fact that it's a web app, and key material is stored in browser local storage.

  62. wgreenhouse

    that is, each browser where you've used movim is its own omemo identity

  63. manday

    Yes, of course.

  64. manday

    But I don't think this is related to browser storage. You can easily reproduce it with a single Movim instance if you follow the description in this bug: https://github.com/movim/movim/issues/1261

  65. pep.

    fwiw (maybe unrelated) the poezio omemo stack isn't using the latest version of the underlying library, it may be a pain to get it to work correctly with all appropriate versions. I recommend using the flatpak stuff for this. I don't think this makes it vulnerable to stuff in particular, the version change was (mostly?) an API redesign and the addition of newmemo support. We should still do the work to upgrade to that someday

  66. wgreenhouse

    I'm so traumatized by that implementation that I don't touch movim

  67. wgreenhouse

    manday: btw, re > however, all images refused to decrypt, but that's a separate issue). I don't think they ever do decrypt in browser

  68. wgreenhouse

    they're offered for download instead

  69. manday

    https://monocles.eu/file_share/c32506f0-37b3-41b7-8e00-23c1de48be17/image.png

  70. pep.

    wgreenhouse, they can't but decrypt in the browser no?

  71. manday

    Well whatever it is, it looks buggy. If they are "only" offered for download (why not display them inline, though? That makes no sense), then no need to render a broken thumbnail. But also, clicking on the link shows a progress bar from 0 to 100% but then... nothing.

  72. wgreenhouse

    > Well whatever it is, it looks buggy. If they are "only" offered for download (why not display them inline, though? That makes no sense), then no need to render a broken thumbnail. But also, clicking on the link shows a progress bar from 0 to 100% but then... nothing. manday: it's because the image preview facility is serverside

  73. wgreenhouse

    so putting cleartext of omemo'd images there is problematic

  74. wgreenhouse

    but yeah, that's a bug, that's not what it's supposed to look like

  75. wgreenhouse

    should just be a download link

  76. manday

    Ah okay, I see. Well then either remove the thumbnail alltogether or let the client render the thumbnail for OMEMO images.

  77. pep.

    Technically it could be done, but that'd be two codepaths for "the same feature"

  78. manday

    Yeah, I get it.

  79. manday

    I also get that encryption is a pain 😐

  80. wgreenhouse

    > but yeah, that's a bug, that's not what it's supposed to look like looks more like a mixed state where omemo is not enabled, I've had movim display garbage like that in that cass

  81. wgreenhouse

    > but yeah, that's a bug, that's not what it's supposed to look like looks more like a mixed state where omemo is not enabled, I've had movim display garbage like that in that case

  82. manday

    Ah, good catch.

  83. wgreenhouse

    manday: I was very attracted to movim for a time because of the "one client everywhere" potential, but these issues, issues with channel bookmarks, and the lack of history search rendered it untenable for me

  84. manday

    Yes indeed, at the time whenthe images were posted I had encryption disabled.

  85. manday

    Yes indeed, at the time when the images were posted I had encryption disabled.

  86. manday

    XMPP won't be a viable option for me without a web client with A/V support, and currently only Movim fits that bill.

  87. wgreenhouse

    sorry

  88. wgreenhouse

    it's not viable yet, IMO

  89. manday

    That's what I'm trying to find out. It's okay for my intended deployment where the users would require little.

  90. wgreenhouse

    the channel bookmarks complaint is that it uses its own, also its own blocklist

  91. wgreenhouse

    so it doesn't stay in sync with other clients

  92. manday

    I had no troubles with bookmarks. They sync well between Monocles and Movim - what's your issue with it?

  93. wgreenhouse

    manday: they don't sync

  94. wgreenhouse

    unless I manually run js console stuff

  95. wgreenhouse

    old bug

  96. manday

    They do for me; but then again there is no explicit notion of bookmarks on Movim, is there...? All MUCs are bookmarks. But adding/removing them syncs well for me..

  97. manday

    Maybe give it another go? Or can you cite a reproducible case I could try?

  98. wgreenhouse

    manday: yes, use ejabberd--that's it

  99. wgreenhouse

    > Maybe give it another go? Or can you cite a reproducible case I could try? gave it a go for a couple years

  100. manday

    I'm on monocles.eu, not sure which server they use. But if you're only seing this on ejabberd instances, may it not be a server issue?

  101. manday

    Well I've been using it for a few days, nothing terrible yet 😅

  102. wgreenhouse

    movim doesn't adhere to best practice when both xep-0048 bookmarks and xep-0402 bookmarks are in use

  103. wgreenhouse

    it just ignores the former

  104. wgreenhouse

    which is what mostly every other client still uses

  105. manday

    Oh well, I wouldn't blame them for deprecating deprecated specs ;-|

  106. manday

    So since it works well for me, I assume Monocles uses 402'er bookmarks only? But that would probably hold for conversations then

  107. wgreenhouse

    manday: or it deploys a serverside mitigation translating between them

  108. manday

    In any event, I've been happy with the combo Monocles/Movim (so far)

  109. manday

    hm

  110. wgreenhouse

    conversations/monocles/etc. still only use 0048

  111. wgreenhouse

    they don't even see 0402, so this is your server being helpful

  112. pep.

    Yeah that's an old bug, old complaints. Movim not checking for the compat flag before using 402 broke many things (and still is)

  113. manday

    Just personally, I'd say Movim does well to abandon the deprecated XEP. I can understand that in practice that makes people unhappy, but I wouldn't necessarily call it Movim's deficit.

  114. wgreenhouse

    it just means I'm unlikely to include it in my suite of clients

  115. manday

    And with whatever serverside mitigation is going on, it seems to work.

  116. pep.

    manday, that's not the issue

  117. manday

    For christ's sake why does my Nickname change back to "manday" every other minute after I changed it to "ManDay"...

  118. pep.

    One can implement the newer spec and use it whenever the server says it's usable, without breaking it for all other clients used for the account

  119. manday

    Probably a bookmark issue 😅

  120. pep.

    ManDay, I'd say this is related to https://codeberg.org/joinjabber/support/issues/6, see also https://docs.modernxmpp.org/client/groupchat/#user-nickname. I guess I personally wish we dropped some of these options and priority were slightly different but..

  121. pep.

    Clients don't all do this anyway. Some just use the jid localpart and put that in the bookmark directly because.

  122. pep.

    Clients don't all do this anyway. Some also use the jid localpart and put that in the bookmark directly because.

  123. ManDay

    It's not just about joining, it's about me *changing* the nick in Movim and instants later it's back to the old version.

  124. ManDay

    When I change it in Moncoles, however, it seems to remain.

  125. pep.

    I don't know. If you can, try to observe how Movim does the nick change, and what changes it back (looking at stanzas sent from your account to the MUC)

  126. pep.

    If bookmarks are updated in the meantime, etc.

  127. ManDay

    my debugging capability is close to zero. How could I observe these data?

  128. ManDay

    I can probably watch XHR requests from Movim (assuming it's not using WS), but that's about it.

  129. pep.

    I guess you could use something like the Gajim's XML console

  130. pep.

    (I guess this will also introduce Gajim's possible bugs to the mix though.. since you don't use it already)