XSF Discussion - 2018-12-18

  1. Ge0rG

    Will MUC subject changes also be stored in a MUC's offline history and replayed on join?

  2. lovetox

    not to my knowledge Ge0rG

  3. lovetox

    this would be akward

  4. Ge0rG

    indeed

  5. lovetox

    im not sure why though, its just a gut feeling

  6. lovetox

    it would be weird in combination with MAM

  7. Maranda

    Not replayed in history *shrugs*

  8. lovetox

    because if you join with max=0 history

  9. lovetox

    then you still receive the subject from the MUC

  10. lovetox

    and afterwards you request MAM

  11. Maranda

    Indeed

  12. lovetox

    and get a bunch of subject changes

  13. lovetox

    but you have the timestamp so you could sort them correctly

  14. Ge0rG

    > because if you join with max=0 history [..] and afterwards you request MAM Are there potential race conditions between sync and live traffic?

  15. lovetox

    i dont think so because you have timestamps

  16. Ge0rG

    1. join 2. request MAM since $last_timestamp 3. live message comes in 4. MAM comes in, eventually containing that last live message

  17. oli

    why awkward? subject changes could be part and context of a conversation.

  18. Maranda

    At most, at least I, record only in http logs the subject changes not the rest

  19. lovetox

    oli i meant protocol wise akward

  20. lovetox

    not that it couldnt be useful

  21. Ge0rG

    oli: because a client might think "the sync is completed"

  22. oli

    right

  23. lovetox

    Ge0rG, you case is does not lead to problems with mam:2

  24. lovetox

    because of stanza-id deduplication

  25. Maranda

    oli: it's not stated in the protocol to begin with that subject changes should go in the history (or otherwise, but it goes against the intentions me thinks)

  26. Ge0rG

    I normally don't deduplicate for live messages, only for MAM syncup

  27. lovetox

    true .. i remember i also dont

  28. lovetox

    but i throw away all messages while a MAM MUC catchup is running

  29. lovetox

    or something like that

  30. lovetox

    i considererd this case, thats what i remember

  31. Ge0rG

    We really need to document all these hairy corner cases

  32. Ge0rG

    also notification suppression

  33. Ge0rG

    Just had a similar discussion with Anu yesterday

  34. Zash

    Did you know: Normal groupchat messages are allowed to have a subject if they have a body too

  35. lovetox

    ah i remember now Ge0rG this still does work with deduplication

  36. lovetox

    because live message gets written into the db first

  37. lovetox

    then mam message comes, and you dedup on that

  38. Ge0rG

    Zash: normal != groupchat

  39. lovetox

    he just means groupchat messages

  40. lovetox

    you have to filter on "has subject but not body"

  41. Zash

    <message type=groupchat><subject>stuff</subject><body>Let's talk about stuff</body></message>

  42. lovetox

    to catch a subject, not just "has subject"

  43. Zash

    That is *not* a MUC subject change

  44. Zash

    Just a groupchat message that happens to have a subject

  45. ralphm

    Indeed. “Note: In accordance with the core definition of XML stanzas, any message can contain a <subject/> element; only a message that contains a <subject/> but no <body/> element shall be considered a subject change for MUC purposes.”

  46. Ge0rG

    Some MUC implementation forbid messages having both body and subject.

  47. Ge0rG

    Still, it doesn't answer my question of whether it's legal to have a subject change in MUC history

  48. ralphm

    I don't see why it shouldn't be in there.

  49. Ge0rG

    ralphm: because of https://xmpp.org/extensions/xep-0045.html#order

  50. Ge0rG

    Of course there are also servers that *don't* send the subject at all if it's not set, so...

  51. ralphm

    Ge0rG: I still don't see the issue. If you are sending message history, that's not 'live messages'

  52. lovetox

    i think this is not easy to implement for servers

  53. Ge0rG

    ralphm: a client needs to be able to distinguish history from live messages

  54. lovetox

    they only should put the first subject change into the archive

  55. lovetox

    afterwards they send the subject to many users, but should not put it into the archive anymore

  56. Ge0rG

    lovetox: every subject change should be in the archive

  57. ralphm

    They already should, no? Message history stanzas have a <delay/> with a from attribute.

  58. lovetox

    ralphm, from attr is not mandatory

  59. lovetox

    and servers dont enforce it

  60. Ge0rG

    ralphm: a <delay/> with a from is not exclusive to history.

  61. lovetox

    also all other messages can also have delay

  62. Ge0rG

    so it's a good indicator, at best.

  63. lovetox

    also the room subject itself can have a delay

  64. ralphm

    Hmm. It says here in 7.2.14: Note well that this means the room subject (and changes to the room subject prior to the current subject) are not part of the discussion history.

  65. ralphm

    Well, that sucks

  66. Ge0rG

    ralphm: ah, thanks. Didn't see that.

  67. lovetox

    why are you interested in this Ge0rG? are you writing code regarding to subject changes?

  68. ralphm

    Good thing that's resolved with MIX.

  69. ralphm

    I.e. there's no subject there, at all.

  70. Ge0rG

    lovetox: I have some legacy code about subject changes. Also a race condition between receiving the subject and receiving the room's disco#info on join

  71. ralphm

    Fortunately, if you want to add such functionality, you'd just have another node for just the room subject.

  72. lovetox

    yeah separation is good for that

  73. lovetox

    Ge0rG, dont you want to disco the muc before you join?

  74. lovetox

    thats recommended if you want to use mam when i remember correctly

  75. Ge0rG

    lovetox: I'll have to change that then

  76. lovetox

    the problem with mam is, that if you join a muc without knowing if it is mam capable

  77. lovetox

    you have to use history in the join, because you dont know about mam

  78. lovetox

    because you can do a join with max=0

  79. lovetox

    and then get the history later

  80. lovetox

    cant*

  81. lovetox

    you have to specifiy on join if you want history or not, so you already need to know about mam

  82. lovetox

    and to make that process faster on rejoins, i would also cache that disco information

  83. Ge0rG

    Yay.

  84. Alex

    hey guys, ready for our member meeting?

  85. Seve

    o/

  86. Zash

    woop

  87. Alex

    okay

  88. Alex bangs the gavel

  89. Alex

    here is our Agenda for today

  90. Alex

    https://wiki.xmpp.org/web/Meeting-Minutes-2018-12-18

  91. Alex

    1) Call for Quorum

  92. Alex

    as you can see 30 members voted via memberbot, so we have a quorum

  93. Alex

    2) Items Subject to a Vote

  94. Alex

    new and returning members, you can see all applicants here: https://wiki.xmpp.org/web/Membership_Applications_Q4_2018

  95. Alex

    3) Opportunity for XSF Members to Vote in the Meeting

  96. Alex

    anyone here who has not voted yet via memberbot and wants to vote now?

  97. Alex

    ok, looks like I can start working on the results then

  98. Seve

    Good! :)

  99. Alex

    4) Announcement of Voting Results

  100. Alex

    when you reload the page you can see the results at: https://wiki.xmpp.org/web/Meeting-Minutes-2018-12-18#Announcement_of_Voting_Results

  101. Alex

    all Reappliers accepted, no new applicants this term

  102. Alex

    congrats to everyone

  103. Seve

    Congratulations :)

  104. Seve

    THank you Alex

  105. Alex

    5) Any Other Business?

  106. Zash

    Not here

  107. Guus

    Nor here

  108. Alex

    6) Formal Adjournment

  109. Alex

    I motion that we adjourn

  110. Guus

    Second

  111. Guus

    -ed

  112. Zash

    +ed²

  113. Guus

    Thank you once again, Alex

  114. Alex bangs the gavel

  115. Link Mauve

    Thanks. :)

  116. Alex

    thank you guys, will send out minutes and update the memebrlist ASAP

  117. Zash

    Thanks Alex

  118. Ge0rG

    Thanks very much. Happy to hear I wasn't demoted.

  119. Alex

    :-P

  120. Ge0rG

    Also what's wrong with you guys? I troll and curse all the time and don't get any negative votes!?

  121. jonas’

    Ge0rG, nobody wants to have to repeat the council vote probably ;-)

  122. Ge0rG

    Heh!

  123. jonas’

    or, y’know, they value your nevertheless useful technical contributions...

  124. Ge0rG

    Can't imagine *that*