XMPP Council - 2021-03-31

  1. jonas’

    1) Roll Call

  2. jonas’ is present

  3. Zash 2

  4. daniel


  5. Ge0rG


  6. jonas’

    no dwd yet, but we can start bashing the agenda already

  7. jonas’

    2) Agenda Bashing

  8. jonas’


  9. jonas’

    assuming no

  10. jonas’

    3) Editor’s Update - Published Content Rating Labels as XEP-0456

  11. jonas’

    4) Items for voting

  12. jonas’

    4a) Deprecate XEP-0013: Flexible Offline Message Retrieval Abstract: This specification defines an XMPP protocol extension for flexible, POP3-like handling of offline messages. The protocol enables a connecting client to retrieve its offline messages on login in a controlled fashion, without receiving a flood of messages. Messages can also be left on the server for later retrieval. URL: https://xmpp.org/extensions/xep-0013.html

  13. jonas’

    Sam has asked for this being deprecated because of the overlap with the (preferable) MAM.

  14. Ge0rG

    I never really liked the 0013 workaround for the MAM use case

  15. Ge0rG

    But we don't have any alternative

  16. Zash

    We already deprecated XEP-0136?!

  17. daniel

    i think I might be one of the few people who actually implment this

  18. daniel

    (very partially)

  19. Ge0rG

    I still think we can deprecate 0013, apparently there is not so much business need to replace it

  20. Ge0rG

    daniel: only the one feature to drop history?

  21. daniel


  22. daniel

    but as Holger (for example) pointed out we currently don’t have a mechanism to replace this

  23. Zash

    With the real underlying problem being that it's unspecified how offline messages and MAM are supposed to work together?

  24. Ge0rG

    Can we come up with something that's better than 0013 but not as cool as bind2 for this?

  25. daniel

    that being said i'm still in favor of deprecating it

  26. jonas’

    we could pull the "clear" protocol from '13 into '313

  27. jonas’

    and then deprecate '13

  28. Ge0rG

    What about "a client that does anything with MAM on connect will get its history dropped"?

  29. daniel

    i don’t think that having or not having a replacement is a strict requirement to deprecate something

  30. Sam

    Or go ahead and deprecate '13 today since it won't break anything to do so, then move the protocol whenever someone wants so we don't have to drag this along forever.

  31. Sam

    Deprecating may even encourage someone to do the work (in fact, I will volunteer, I made some modifications to 313 recently and can probably find time to do more)

  32. Kev

    Or Bind2! What could go wrong? :)

  33. daniel

    moving the clear protocol into 313 sounds like a good intermediate solution

  34. Ge0rG

    It's a horrible non-solution.

  35. Sam

    *nods* or bind2. That may need further discussion.

  36. daniel

    because i don’t have a lot of hope for bind2 to happen any time soon

  37. jonas’

    me neither

  38. Ge0rG

    We already have enough racy corner cases in 313 without the "delete all history *now*"

  39. daniel

    you keep saying this. but i don’t find MAM to be all that terrible

  40. Kev

    I’m hoping to implement it later in the year, but yeah. I just want to note it’s not true to say we have no replacement, as Bind2 covers that case (and, indeed, this ‘how to deal with history and startup sync and stuff) is why it exists.

  41. daniel

    even when used with a drop history now command

  42. Ge0rG

    daniel: it's only not terrible if you execute the steps in the magically right but not documented order

  43. Sam

    Sounds like feedback for the 313 last call?

  44. Ge0rG

    in a perfect world, a server implementation should store MAM and offline history in the same database, and keep a (per client) marker from where to send offline history

  45. daniel

    are we in agreement that we do want to have a 'drop history' feature that isn’t bind2?

  46. daniel

    should we check with the MAM authors if they are ok with adding that before we deprecate 13?

  47. Ge0rG

    I'm ambivalent regarding that feature

  48. Zash

    Ge0rG, yeah, turning offline messages into an implicit MAM query for non-supporting clients would be interesting. Like what Prosody does with MUC (legacy) history

  49. Ge0rG

    Sam: I think I wrote that to the ML as feedback to the initial 313 submission some many years ago. Does that count?

  50. Zash

    Does it need to go in 313?

  51. Sam

    Ge0rG: no, absolutely not, because this is another LC and finding things beyond a day ago in a mailing list is impossible :)

  52. Zash

    Once we're away from offline messages entirely, is such a feature needed?

  53. daniel

    well there are benefits of putting it into 313

  54. daniel

    because Conversations currently needs to check mam preference before executing 13 delete

  55. Zash

    daniel, but mam prefs aren't in 313 anymore

  56. daniel

    having that command in 313 would actually make that easier

  57. daniel


  58. Zash

    Put it in a new XEP or whatever 🤷️

  59. Zash

    That way it can be deprecated if we figure out a better way

  60. Ge0rG

    What about "do not deliver offline messages to a MAM client" and "expire old messages from offline history if full instead of rejecting new ones"?

  61. Ge0rG

    daniel: would there be harm in adding the former statement into 0313?

  62. Kev

    I disagree with Ge0rG’s perfect world, incidentally, because I don’t believe there’s any need for a per-client offline store. Users are unlikely to care which clients have and haven’t received messages, they just want their messages.

  63. Kev

    The perfect world has no offline messages at all :)

  64. Ge0rG

    Kev: users want their messages on all their clients and not on a random subset. And from that, you can easily derive my proposal ;)

  65. Zash

    `module:unload"offline"` there, I fixed it

  66. jonas’

    ok, so, where are we at with Deprecating '13?

  67. Ge0rG

    Imagine we could fix the perceived XMPP reliability for all the victims of pidgin, at a very low cost?

  68. Kev

    I’d also not be inclined to shove offline message stuff in 313 as a temporary holding, unless we don’t intend advancing 313. Just shove it in something new until we solve bind2 in whatever way we solve it.

  69. jonas’

    I see that there are arguments about how MAM catchup may be improved, but those are only tangentially related to the '13 deprecation.

  70. Zash

    jonas’, +1 then

  71. Kev

    What is the proposal, other than using bind2 or something akin to bind2, to tell your server that you’re a mam client and not to send offline messages?

  72. Ge0rG

    +1 for deprecating 0013

  73. daniel


  74. jonas’


  75. jonas’

    ok, then we’ve got that sorted and everything else can go in the '313 LC thread which is *still active* or in a separate bind2 design discussion on-list

  76. jonas’


  77. Ge0rG

    Kev: my proposal is just to not send offline messages to any MAM capable client

  78. Kev

    Yes. How does the server tell it’s a MAM capable client?

  79. daniel

    I actually have a bunch of setups where we very deliberatly don’t do MAM in favor of offline messages

  80. jonas’

    I’d like to move on with the meeting and defer any further discussion to xsf@

  81. daniel

    but we don’t need 13 for these setups

  82. jonas’

    5) Pending Votes - none from before this meeting

  83. jonas’

    6) Date of Next

  84. jonas’

    +1w wfm

  85. daniel


  86. Sam

    Wasn't there a vote missing? I presume they're on list then?

  87. Ge0rG

    +1W WFM

  88. jonas’

    Sam, dwd is AFK, so yeah.

  89. Zash

    +7d wfm

  90. jonas’


  91. jonas’

    7) AOB

  92. jonas’

    I’ve got one from just now

  93. jonas’

    do we want to move Council meetings to xsf@?

  94. Zash

    I'm not opposed

  95. jonas’

    I see that we often start discussions here which are then hard to carry over to xsf@

  96. Zash

    Always did seem weird to have board meetings there but not council meetings

  97. Kev

    I see no reason to do it, and (probably not hugely important) reasons not to.

  98. jonas’

    and we might get more input during the meeting (which may also incur more noise, mind)

  99. Ge0rG

    Wasn't the Council meeting moved out of xsf@ to make it less noisy?

  100. Zash

    We could try, easy enough to move back.

  101. Kev

    I don’t recall Council ever being in xsf@, but I might just have blocked that out of my memory.

  102. jonas’

    Do we just want to give it a shot for next week and see where it leads us?

  103. Kev

    One significant advantage of leaving it here is filtering.

  104. Kev

    xsf@ is noisy and I frequently ignore it for the best part of a day, but once I see stuff happening in council@ I realise it’s council time and I try to pay some attention.

  105. daniel

    i actually don’t really like board meetings to be in xsf@

  106. Kev

    And if I want to read what happened in council because I missed it, it’s easily delineated by being here.

  107. daniel

    and i'd prefer to keep council meetings in here

  108. Zash

    Maybe the real issue is that there's no exact equivalent to the standards@ ML

  109. Ge0rG

    also a weak preference for staying here

  110. jonas’


  111. jonas’

    let’s stay here then :)

  112. daniel

    not for council's or board's sake but for the sake of the people in there who might have a different discussion going on at the time

  113. jonas’

    daniel, yes, another good reason to stay here

  114. jonas’

    alright, AO-AOB?

  115. Zash

    It /is/ easier to set this room as higher priority (notification-wise) than figure out some time based rules for xsf@

  116. Zash

    (I've got no ao²b)

  117. Kev

    Jonas - just noting that while I understand your desire to stay on time and curtail discussion, I think it would have been of value for Council to give guidance on what to do instead at the same time as deprecating 13 (with which I vaguely agree).

  118. jonas’

    alright then

  119. jonas’

    Kev, oh---

  120. jonas’

    Kev, instead of what, mind?

  121. Kev

    Instead of using 13 as the MAM cludge.

  122. jonas’

    ... use MAM?

  123. Ge0rG

    > This Last Call begins today and shall end at the close of business on 2021-03-30. I'm too late :(

  124. Zash

    Note when the client uses MAM (prefs?) before <presence/>, ???, PROFIT!

  125. jonas’

    Ge0rG, oh, missed than when I prepped the agenda :(

  126. Ge0rG

    What Zash said.

  127. Sam

    Or maybe deprecate 13 then the guidance is "start implementing bind2" and this is what puts pressure on people to actually use it?

  128. Kev

    jonas’ use MAM on its own doesn’t solve the duplication issue that people are using 13 for.

  129. Ge0rG

    When a client queries MAM or MAM prefs, let the server omit offline history on presence

  130. Ge0rG

    Kev: which issue?

  131. jonas’

    Kev, I mean, personally I’d guide people to continue to use that single bit of the deprecated '13

  132. jonas’

    this does make sufficient sense to me

  133. Kev

    Ge0rG: That you log in and request history, but you also get sent offline messages that duplicate what’s in the history. Or have I completely misunderstood?

  134. Sam

    or what jonas’ said.

  135. jonas’

    (just like you still have to do RFC 3920 session stuff with some servers; even though it’s deprecated, you might need bits and pieces to work with deprecated servers)

  136. Ge0rG

    Kev: see Zash's and my proposals above?

  137. Kev

    Ge0rG: I saw you propose not to send offline to MAM clients (which is right), but I don’t think you replied to my question on how (short of bind2) the server should determine it’s a mam-capable client before sending the offline messages.

  138. Kev

    The options I can think of add roundtrips, which make them pretty much non-options.

  139. Kev

    (Like doing disco on the client)

  140. Zash

    Kev, a MAM-capable client would be asking for MAM prefs probably?

  141. Ge0rG

    Kev: that's what Zash proposed above, keep a flag on the c2s session that's set to "MAM" when the client does any MAM activity

  142. Zash

    Prosody has a "smart enable" setting for MAM that gets enabled when the client does something MAM-related

  143. Ge0rG

    Kev: because of MAM race condition weirdness, a client must essentially ask for the last MAM stored ID before sending initial presence

  144. Zash

    Could extend that logic to stop offline broadcast

  145. Ge0rG

    The MAM race condition weirdness that nobody but me is obsessed about.

  146. Kev

    Ge0rG: That would be the ‘add a roundtrip’ that I’m proposing isn’t much of an option.

  147. Zash

    You would have to do so before the initial p resence

  148. Zash

    You would have to do so before the initial presence

  149. Kev

    Actually, you don’t have to wait for reply, you can pipeline it.

  150. Ge0rG

    Kev: the client can pipeline MAM prefs / MAM query / presence.

  151. Kev

    The client doesn’t need to do MAM prefs does it?

  152. daniel

    Conversations uses MAM prefs to decide if it wants to purge

  153. Kev

    So we’re saying essentially send an empty MAM query (or limit 1) before sending initial presence is the fix?

  154. daniel

    but obviously not pipelined

  155. Ge0rG

    Kev: it's not the fix but a pragmatic solution suggestion

  156. Zash

    XEP wishlist: "How to deal with offline messages in the presence of MAM"

  157. Ge0rG

    I'm very much interested in the side effects.

  158. Ge0rG

    Kev: does your implementation not send a MAM query prior to initial presence?

  159. Kev

    So we need a new XEP that says “If a client requests MAM prior to offline messages being sent, dump the offline store. As a client, request MAM before initial presence”?

  160. Kev

    Ge0rG: My current implementation only requests MAM when you open a chat, for some context to fill it with.

  161. Zash

    Kev, ^C^V that into a xep, title it "How to deal with offline messages in the presence of MAM", call it a day? 🙂

  162. daniel

    > So we need a new XEP that says “If a client requests MAM prior to offline messages being sent, dump the offline store. As a client, request MAM before initial presence”? either that or a conditional purge

  163. Zash

    Kev, does your implementation *not* want offline messages in this case?

  164. Kev

    Zash: I don’t think that’s a bad option. I might even do that now, as my migraine hangover means I can’t do much else of value today.

  165. daniel

    a purge if i have mam enabled command

  166. daniel

    that can be send right before initial presence

  167. Ge0rG

    Kev: you could send initial presence with a negative priority and enable carbons.

  168. Kev

    Zash: My implementation basically wants bind2, and everything that comes with that (currently specified and not yet specified).

  169. Kev

    Because I don’t want to do full-sync, I want to do current-state-sync (inbox stylee)

  170. jonas’

    I do appreciate the discussion and I see that it’s of value to provide more guidance.

  171. Zash

    Type that sentence into the wiki in the section for hacks to do until we get bind2?

  172. jonas’

    My current view is that the trivial solution is to simply use the clearing bits of '13 as needed

  173. jonas’

    anything more complex should go to the list, either in the form of a thread or as a protoxep submission

  174. jonas’

    any objections to me closing the meeting with that conclusion?

  175. Zash


  176. Kev

    No. Thanks for letting us reach some sort of conclusion.

  177. jonas’

    alright then

  178. jonas’

    8) Ite Meeting Est

  179. jonas’

    Thanks Tedd, Thanks Kev (for reminding me about the discussion I cut off earlier), Thanks everyone!

  180. Zash

    Thanks all

  181. Sam

    Thanks fo rthe interesting discussion. I'll create a thread on list right now (unless someone else would prefer to do it)

  182. Zash

    Thanks Sam, please do 🙂

  183. jonas’

    Yes, please go ahead

  184. Ge0rG is commenting on the 313 LC

  185. Ge0rG

    but that might not cover all points.

  186. Kev

    I need to read 313 properly (or at least a diff since I last understood it) before replying to the LC. I’ve just not found the time yet.

  187. Zash

    That sounds like a thing I should have done too

  188. Ge0rG

    Zash: it's not too late.

  189. Zash

    Didn't I reply already?

  190. Ge0rG

    Zash: sure, but you can reply to yourself

  191. Zash


  192. Sam


  193. Kev

    Might it make sense to simply write a new XEP containing that one iq from 13?

  194. Kev

    Anyway, moved beyond Council now, I’ll take it to list.

  195. Ge0rG

    Kev: ...and call it 0013.

  196. Zash


  197. Kev

    Stripping a small part of a spec out into another spec is not without precedent.

  198. Ge0rG

    Why not removing all the unneeded parts of 0013?

  199. Sam

    That does seem like an easy temporary solution until bind2 or whatever is a thing. Probably worth discussion others first though in case there's a good permanent solution that can be done now-ish.

  200. Sam

    Removing other parts of 0013 feels wrong to me, but I can't really think why. It's sort of a Ship of Theseus problem I guess: when is it a new XEP and therefore should have a new number?

  201. Sam

    But I don't really care either way.

  202. jonas’

    my argument against removing '13 is how indiscoverable old XEP versions are

  203. jonas’

    someone who has to deal with an implementation based on '13 would have a hard time figuring out what the heck is going on

  204. daniel

    If we externalize it I'd really like to include the conditional part

  205. Sam

    jonas’ if we mark 13 as superseded by whatever the new thing is, wouldn't that add a link and make it easier?

  206. Kev

    daniel: “the conditional part”?

  207. daniel

    Purge only if mam preference is set to always

  208. Zash

    jonas’, for the general version discovery problem, could the xep xslt be tweaked to link to the attic?

  209. daniel

    Or at least not to never

  210. daniel

    Then I don't have to do the conditional part on the client side

  211. daniel

    This would allow me to properly pipe line it

  212. Ge0rG

    daniel: that's an excellent suggestion, except when offline history goes longer than MAM

  213. Ge0rG

    So my one day too late feedback for MAM has become a very long email in which I try to solve World Peace, it seems.

  214. daniel

    > daniel: that's an excellent suggestion, except when offline history goes longer than MAM fair but i still take that over a blind purge

  215. Kev

    World Peace is why I’m in no particular rush to advance MAM, FWIW, but am in a rush to get implementation experience of Bind2 and MIX and the like. Because although I appreciate the dangers of second system, so many things are subtly (or sometimes not) broken around what we currently have that we keep having bits that never fit together for a jigsaw.

  216. Ge0rG

    Kev: yeah, we are kludging workarounds for workaround for designs from twenty years ago

  217. Kev

    I am not for a moment suggesting we bin everything and start again. But I am suggesting at some point there’s value in fixing stuff.

  218. Sam

    Maybe I'll add a "Towards XMPP 2.0" roundtable discussions to office hours for the week afte rnext

  219. Ge0rG

    Office hours collides with private appointments for me, but the alternative slots collided with business appointments, so I didn't even submit the form.

  220. Sam

    Ge0rG: it's not a strict time, just a "default" time (since I think there's some value at it mostly being consistent every week). If you want to present or something feel free to add a different time in the signup sheet.

  221. Ge0rG

    Sam: I'm spending my days with a headset and I'm really glad to be able to go and do some garden work after that

  222. Sam

    Ge0rG: I know the feeling. Despite the fact that this season I haven't even started my garden and now I desperately need to run to the Feed & Seed and try to get something established before it's too hot

  223. Ge0rG

    Also I'm not sure what I'd present, except for my "what's wrong with xmpp in 2017" talk with very minor changes.

  224. Zash looks out over the remaining snow

  225. Sam

    Ge0rG: a demo of yax.im (or new features in yax.im or whatever) might be good

  226. Ge0rG is standing in the queue at the ice dealer

  227. Ge0rG

    ...wearing a t-shirt

  228. Sam

    But also that what's wrong with xmpp talk would be a good one

  229. Ge0rG

    I'd probably break out in tears because so little changed since 2017

  230. Sam

    That would make a great presentation! You could win an Oscar!

  231. Ge0rG

    Well, MattJ has done much better work on easy invitations than what I pioneered in yaxim back then

  232. Sam

    That would still be a great thing to demo, even if you didn't write it.

  233. daniel

    > Maybe I'll add a "Towards XMPP 2.0" roundtable discussions to office hours for the week afte rnext I'd join that discussion

  234. daniel

    I have thoughts