jdev - 2023-07-10

  1. nicoco

    about xep-0421, should the occupant-id also be attached to the <message> containing the <subject> of the MUC?

  2. lovetox

    I would say yes, does anything in the XEP say otherwise?

  3. nicoco

    it does not, and I think yes too, but wanted to make sure there wasn't something I didn't think of :)

  4. nicoco

    Even though it's deferred because reasons, consensus is that this XEP is good, amirite? or are there opponents to it? for context, slidge mucs are all non anonymous right now, so I thought it didn't make sense to support that. but if a participant changes its name while a client is offline, this is the only for the client to establish a relationship between a MAM message and this new name. do I understand this right? ✎

  5. nicoco

    Even though it's deferred because reasons, consensus is that this XEP is good, amirite? or are there opponents to it? for context, slidge mucs are all non anonymous right now, so I thought it didn't make sense to support that. but if a participant changes its name while a client is offline, this is the only way for the client to establish a relationship between a MAM message and this new name. do I understand this right? ✏

  6. Zash

    nicoco, correct

  7. nicoco

    thanks. that may be why I got dino starting to say that "reactions are not supported in this group" in a group where it definitely worked before then, I guess.

  8. Zash

    nick changes that you don't directly observe can cause confusion, occupant-id solves this

  9. nicoco

    I'll just use the contact's JID as a unique identifier then, there's nothing wrong with that, right?

  10. Zash

    I forget, do you see that in MAM?

  11. lovetox

    Jids need to be attached to every mam message

  12. nicoco

    I don't know about other implementations, but slidge as a MAM server will attach occupant-id to MAM messages, that's the point :)

  13. nicoco

    > Jids need to be attached to every mam message huh? you mean room@conference/nickname is attached to every MAM message, but myrealjid@myserver.com isn't? or is it‽

  14. lovetox

    No the real jid

  15. lovetox

    Otherwise it's not non-anon

  16. nicoco

    looks like the room just "ate" my latest rather long message, damn

  17. Zash

    om nom nom

  18. Zash

    nicoco, do you have a timestamp of when you sent it?

  19. nicoco

    about 15:31 paris time I think. I know I left and re-join the MUC just after and gajim shows my re-join at 15:33.

  20. Zash

    I see a message with id `56ab9092-9c63-4895-bba0-71c100d109e2` received and broadcast

  21. Zash

    I see it in my own logs. Guess you managed to make an invisible message. gg

  22. nicoco

    gg gajim. not me :)

  23. Zash

    Wasn't archived anywhere so no idea what it was

  24. Link Mauve

    Zash, unlikely to be that one: 490179 2023-07-10 15:31:23,420 DEBUG:xmlstream:RECV: <message from="jdev@muc.xmpp.org/nicoco" type="groupchat" xml:lang="en" id="56ab9092-9c63-4895-bba0-71c100d109e2" to="*me*"><origin-id xmlns="urn:xmpp:sid:0" id="56ab9092-9c63-4895-bba0-71c100d109e2" /><paused xmlns="http://jabber.org/protocol/chatstates" /><no-store xmlns="urn:xmpp:hints" /><occupant-id xmlns="urn:xmpp:occupant-id:0" id="FupMtP4zOtNXvGoPd0dQhaljq9W4ej4xyxnycZDYDJg=" /></message>

  25. Zash

    Ah

  26. Link Mauve

    nicoco, I see you sending paused (15:31:07), composing (15:31:09), paused (15:31:23), composing (15:31:31), then you leave the room (15:33:24).

  27. Zash

    rate limits?

  28. nicoco

    well, it probably is a gajim bug then, because before leaving the room I pressed Enter and waited for a 1 or 2 minutes before leaving ✎

  29. nicoco

    well, it probably is a gajim bug then, because before leaving the room I pressed Enter and waited for 1 or 2 minutes before leaving ✏

  30. Zash

    aha!

  31. Zash

    `033cb99c-05b3-43ae-9b12-2879fd4c80e3` > Dropping stanza for jdev@muc.xmpp.org from <nicoco>, over rate limit

  32. Zash

    Report to Gajim for not showing you that error I guess?

  33. nicoco

    Gajim does not display anything until the MUC echoes the message. Does the MUC component here even send an error msg btw or just silently drops the stanza when rate limiting?

  34. nicoco

    damn, over rate limit, it was not *that* long but I guess the composing/paused/composing/paused/... didn't help

  35. nicoco

    oh, adding that occupant-id made me realize that my <subject> messages didn't have <stanza-id> either, that wasn't good

  36. Zash

    should it?

  37. nicoco

    > https://xmpp.org/extensions/xep-0313.html#business-storeret-muc-archives All messages sent to the room that contain a <body> element SHOULD be stored, as should subject change stanzas, apart from those messages that the room rejects. ✎

  38. nicoco

    from https://xmpp.org/extensions/xep-0313.html#business-storeret-muc-archives > All messages sent to the room that contain a <body> element SHOULD be stored, as should subject change stanzas, apart from those messages that the room rejects. ✏

  39. nicoco

    so it kindof sounds like it should?

  40. Zash

    in prosody we're storing subject outside of the archive :/

  41. nicoco

    or should we consider the "subject that concludes the join sequence" a special case?

  42. Zash

    dunno

  43. Zash

    It is a special case in some ways

  44. nicoco

    to me it looks like it should have this <stanza-id>, but I'm probably biased because it makes me add a lot of crap to my already crappy code to not include it, but that's not a valid reason I guess. if anyone sees a reason why a stanza-id should not be there, ping me.

  45. lovetox

    nicoco, yes its true muc message erros might not be shown in Gajim currently

  46. lovetox

    but we plan to change that and switch to showing the message in the chat even if it didnt reach the muc yet

  47. lovetox

    on another note, real jid must be attached to all MAM messages in non-anon rooms

  48. lovetox

    you do that hopefully :)

  49. nicoco

    I don't. so this would make occupant-id useless I guess :(

  50. nicoco

    I missed this part of the MAM spec…

  51. lovetox

    i mean, in Gajim we only use it for OMEMO

  52. lovetox

    which is not usable over your bridge anyway i guess

  53. nicoco

    nope

  54. lovetox

    and no please implement occupant-id

  55. nicoco

    indeed: > In the case of non-anonymous rooms or if the recipient of the MUC archive has the right to access the sender real JID at the time of the query, the archive message will use extended message information in an <x/> element qualified by the 'http://jabber.org/protocol/muc#user' namespace and containing an <item/> child with a 'jid' attribute specifying the occupant's full JID, as defined for non-anonymous room presence in Multi-User Chat (XEP-0045) [11]. The archiving entity MUST strip any pre-existing <x> element from MUC messages (as MUC rooms are not required to do this).

  56. nicoco

    there's no MUST… 🤡️

  57. singpolyma

    It says "will"

  58. singpolyma

    > and no please implement occupant-id For a non-anon room? Why? ↺

  59. lovetox

    it makes implementation much easier

  60. lovetox

    occupant-id is added to every message

  61. lovetox

    real jid not

  62. lovetox

    you always have to do a mapping to the roster

  63. lovetox

    which im not planning to do

  64. lovetox

    why would i need to completely different code paths for the same feature, depending on some muc config setting

  65. lovetox

    nicoco, the XEP says > a MUC service SHOULD generate the identifier such that the occupant identifier of a user in one room of the service does not match the occupant identifier of the same user in another room of the same service.

  66. lovetox

    i currently rewrite my database schema, and my first idea was that occupant-id is globally unique

  67. lovetox

    but i now think its safer to make it a occupant-id / room-jid tuple

  68. singpolyma

    Could put real jid in the occupant id column when known and there is no occupant id or similar to keep it not two whole code paths. Going to be something one encouters in the wild for some time either way

  69. lovetox

    mhm, sounds maybe like a good idea

  70. lovetox

    i wonder though what would happen if the server suddenly supports occupant-id then

  71. pep.

    singpolyma, and then the MUC implements occupant-id and you think it's been changed :P

  72. singpolyma

    Sure, same as going from null to something except a bit better?

  73. lovetox

    damnit i hate that sqlite treats NULL always as unique

  74. lovetox

    it really might be the easiest thing to just set realjid = occupant-id for the servers that dont support it

  75. lovetox

    with the downside that the link breaks, if the server introduces occupant-ids

  76. lovetox

    though the features for what i would need this are maybe not that important

  77. lovetox

    mostly "show me all messages from this user" search option

  78. lovetox

    hm but i guess i could work around that simply searching for the occupant-id and the real jid

  79. lovetox

    or something