XMPP Council - 2021-03-31

  1. paul has left
  2. Lance has left
  3. Syndace has left
  4. Syndace has joined
  5. Zash has left
  6. B has left
  7. B has joined
  8. David has left
  9. David has joined
  10. B has left
  11. B has joined
  12. Tobias has joined
  13. paul has joined
  14. dwd has joined
  15. Zash has joined
  16. Lance has joined
  17. debacle has joined
  18. Wojtek has joined
  19. Guus has joined
  20. B has left
  21. paul has left
  22. paul has joined
  23. paul has left
  24. paul has joined
  25. paul has left
  26. paul has joined
  27. paul has left
  28. paul has joined
  29. Guus has left
  30. B has joined
  31. dwd has left
  32. dwd has joined
  33. Wojtek has left
  34. B has left
  35. B has joined
  36. Wojtek has joined
  37. Guus has joined
  38. B has left
  39. B has joined
  40. Guus has left
  41. B has left
  42. B has joined
  43. B has left
  44. B has joined
  45. jonas’ 1) Roll Call
  46. jonas’ is present
  47. Zash 2
  48. daniel Hi
  49. Ge0rG Hi
  50. jonas’ no dwd yet, but we can start bashing the agenda already
  51. jonas’ 2) Agenda Bashing
  52. jonas’ anyhting?
  53. jonas’ assuming no
  54. jonas’ 3) Editor’s Update - Published Content Rating Labels as XEP-0456
  55. jonas’ 4) Items for voting
  56. 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
  57. jonas’ Sam has asked for this being deprecated because of the overlap with the (preferable) MAM.
  58. Ge0rG I never really liked the 0013 workaround for the MAM use case
  59. Ge0rG But we don't have any alternative
  60. Zash We already deprecated XEP-0136?!
  61. daniel i think I might be one of the few people who actually implment this
  62. daniel (very partially)
  63. Ge0rG I still think we can deprecate 0013, apparently there is not so much business need to replace it
  64. Ge0rG daniel: only the one feature to drop history?
  65. daniel yes
  66. daniel but as Holger (for example) pointed out we currently don’t have a mechanism to replace this
  67. Zash With the real underlying problem being that it's unspecified how offline messages and MAM are supposed to work together?
  68. Ge0rG Can we come up with something that's better than 0013 but not as cool as bind2 for this?
  69. daniel that being said i'm still in favor of deprecating it
  70. jonas’ we could pull the "clear" protocol from '13 into '313
  71. jonas’ and then deprecate '13
  72. Ge0rG What about "a client that does anything with MAM on connect will get its history dropped"?
  73. daniel i don’t think that having or not having a replacement is a strict requirement to deprecate something
  74. 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.
  75. 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)
  76. Kev Or Bind2! What could go wrong? :)
  77. daniel moving the clear protocol into 313 sounds like a good intermediate solution
  78. Ge0rG It's a horrible non-solution.
  79. Sam *nods* or bind2. That may need further discussion.
  80. daniel because i don’t have a lot of hope for bind2 to happen any time soon
  81. jonas’ me neither
  82. Ge0rG We already have enough racy corner cases in 313 without the "delete all history *now*"
  83. daniel you keep saying this. but i don’t find MAM to be all that terrible
  84. 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.
  85. daniel even when used with a drop history now command
  86. Ge0rG daniel: it's only not terrible if you execute the steps in the magically right but not documented order
  87. Sam Sounds like feedback for the 313 last call?
  88. 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
  89. daniel are we in agreement that we do want to have a 'drop history' feature that isn’t bind2?
  90. daniel should we check with the MAM authors if they are ok with adding that before we deprecate 13?
  91. Ge0rG I'm ambivalent regarding that feature
  92. 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
  93. Ge0rG Sam: I think I wrote that to the ML as feedback to the initial 313 submission some many years ago. Does that count?
  94. Zash Does it need to go in 313?
  95. Sam Ge0rG: no, absolutely not, because this is another LC and finding things beyond a day ago in a mailing list is impossible :)
  96. Zash Once we're away from offline messages entirely, is such a feature needed?
  97. daniel well there are benefits of putting it into 313
  98. daniel because Conversations currently needs to check mam preference before executing 13 delete
  99. Zash daniel, but mam prefs aren't in 313 anymore
  100. daniel having that command in 313 would actually make that easier
  101. Wojtek has left
  102. daniel details…
  103. Zash Put it in a new XEP or whatever 🤷️
  104. Zash That way it can be deprecated if we figure out a better way
  105. 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"?
  106. Ge0rG daniel: would there be harm in adding the former statement into 0313?
  107. 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.
  108. Kev The perfect world has no offline messages at all :)
  109. 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 ;)
  110. Zash `module:unload"offline"` there, I fixed it
  111. jonas’ ok, so, where are we at with Deprecating '13?
  112. Ge0rG Imagine we could fix the perceived XMPP reliability for all the victims of pidgin, at a very low cost?
  113. 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.
  114. jonas’ I see that there are arguments about how MAM catchup may be improved, but those are only tangentially related to the '13 deprecation.
  115. Zash jonas’, +1 then
  116. 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?
  117. Ge0rG +1 for deprecating 0013
  118. daniel +1
  119. jonas’ +1
  120. 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
  121. jonas’ thanks
  122. Ge0rG Kev: my proposal is just to not send offline messages to any MAM capable client
  123. Kev Yes. How does the server tell it’s a MAM capable client?
  124. daniel I actually have a bunch of setups where we very deliberatly don’t do MAM in favor of offline messages
  125. jonas’ I’d like to move on with the meeting and defer any further discussion to xsf@
  126. daniel but we don’t need 13 for these setups
  127. jonas’ 5) Pending Votes - none from before this meeting
  128. jonas’ 6) Date of Next
  129. jonas’ +1w wfm
  130. daniel m2
  131. Sam Wasn't there a vote missing? I presume they're on list then?
  132. Ge0rG +1W WFM
  133. jonas’ Sam, dwd is AFK, so yeah.
  134. Zash +7d wfm
  135. jonas’ great!
  136. jonas’ 7) AOB
  137. jonas’ I’ve got one from just now
  138. jonas’ do we want to move Council meetings to xsf@?
  139. Zash I'm not opposed
  140. jonas’ I see that we often start discussions here which are then hard to carry over to xsf@
  141. Zash Always did seem weird to have board meetings there but not council meetings
  142. Kev I see no reason to do it, and (probably not hugely important) reasons not to.
  143. jonas’ and we might get more input during the meeting (which may also incur more noise, mind)
  144. Ge0rG Wasn't the Council meeting moved out of xsf@ to make it less noisy?
  145. Zash We could try, easy enough to move back.
  146. Kev I don’t recall Council ever being in xsf@, but I might just have blocked that out of my memory.
  147. jonas’ Do we just want to give it a shot for next week and see where it leads us?
  148. Kev One significant advantage of leaving it here is filtering.
  149. 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.
  150. daniel i actually don’t really like board meetings to be in xsf@
  151. Kev And if I want to read what happened in council because I missed it, it’s easily delineated by being here.
  152. daniel and i'd prefer to keep council meetings in here
  153. Zash Maybe the real issue is that there's no exact equivalent to the standards@ ML
  154. Ge0rG also a weak preference for staying here
  155. jonas’ okay
  156. jonas’ let’s stay here then :)
  157. 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
  158. jonas’ daniel, yes, another good reason to stay here
  159. jonas’ alright, AO-AOB?
  160. Zash It /is/ easier to set this room as higher priority (notification-wise) than figure out some time based rules for xsf@
  161. Zash (I've got no ao²b)
  162. 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).
  163. jonas’ alright then
  164. jonas’ Kev, oh---
  165. jonas’ Kev, instead of what, mind?
  166. Kev Instead of using 13 as the MAM cludge.
  167. jonas’ ... use MAM?
  168. Ge0rG > This Last Call begins today and shall end at the close of business on 2021-03-30. I'm too late :(
  169. Zash Note when the client uses MAM (prefs?) before <presence/>, ???, PROFIT!
  170. jonas’ Ge0rG, oh, missed than when I prepped the agenda :(
  171. Ge0rG What Zash said.
  172. Sam Or maybe deprecate 13 then the guidance is "start implementing bind2" and this is what puts pressure on people to actually use it?
  173. Kev jonas’ use MAM on its own doesn’t solve the duplication issue that people are using 13 for.
  174. Ge0rG When a client queries MAM or MAM prefs, let the server omit offline history on presence
  175. Ge0rG Kev: which issue?
  176. jonas’ Kev, I mean, personally I’d guide people to continue to use that single bit of the deprecated '13
  177. jonas’ this does make sufficient sense to me
  178. 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?
  179. Sam or what jonas’ said.
  180. 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)
  181. Ge0rG Kev: see Zash's and my proposals above?
  182. paul has left
  183. paul has joined
  184. 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.
  185. Kev The options I can think of add roundtrips, which make them pretty much non-options.
  186. Kev (Like doing disco on the client)
  187. Zash Kev, a MAM-capable client would be asking for MAM prefs probably?
  188. 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
  189. Zash Prosody has a "smart enable" setting for MAM that gets enabled when the client does something MAM-related
  190. Ge0rG Kev: because of MAM race condition weirdness, a client must essentially ask for the last MAM stored ID before sending initial presence
  191. Zash Could extend that logic to stop offline broadcast
  192. Ge0rG The MAM race condition weirdness that nobody but me is obsessed about.
  193. Kev Ge0rG: That would be the ‘add a roundtrip’ that I’m proposing isn’t much of an option.
  194. Zash You would have to do so before the initial p resence
  195. Zash You would have to do so before the initial presence
  196. Kev Actually, you don’t have to wait for reply, you can pipeline it.
  197. Ge0rG Kev: the client can pipeline MAM prefs / MAM query / presence.
  198. paul has left
  199. Kev The client doesn’t need to do MAM prefs does it?
  200. daniel Conversations uses MAM prefs to decide if it wants to purge
  201. Kev So we’re saying essentially send an empty MAM query (or limit 1) before sending initial presence is the fix?
  202. daniel but obviously not pipelined
  203. paul has joined
  204. Ge0rG Kev: it's not the fix but a pragmatic solution suggestion
  205. Zash XEP wishlist: "How to deal with offline messages in the presence of MAM"
  206. Ge0rG I'm very much interested in the side effects.
  207. Ge0rG Kev: does your implementation not send a MAM query prior to initial presence?
  208. 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”?
  209. Kev Ge0rG: My current implementation only requests MAM when you open a chat, for some context to fill it with.
  210. 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? 🙂
  211. 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
  212. Zash Kev, does your implementation *not* want offline messages in this case?
  213. 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.
  214. daniel a purge if i have mam enabled command
  215. daniel that can be send right before initial presence
  216. Ge0rG Kev: you could send initial presence with a negative priority and enable carbons.
  217. Kev Zash: My implementation basically wants bind2, and everything that comes with that (currently specified and not yet specified).
  218. Kev Because I don’t want to do full-sync, I want to do current-state-sync (inbox stylee)
  219. jonas’ I do appreciate the discussion and I see that it’s of value to provide more guidance.
  220. Zash Type that sentence into the wiki in the section for hacks to do until we get bind2?
  221. jonas’ My current view is that the trivial solution is to simply use the clearing bits of '13 as needed
  222. jonas’ anything more complex should go to the list, either in the form of a thread or as a protoxep submission
  223. jonas’ any objections to me closing the meeting with that conclusion?
  224. Zash sgtm
  225. Kev No. Thanks for letting us reach some sort of conclusion.
  226. jonas’ alright then
  227. jonas’ 8) Ite Meeting Est
  228. jonas’ Thanks Tedd, Thanks Kev (for reminding me about the discussion I cut off earlier), Thanks everyone!
  229. Zash Thanks all
  230. Sam Thanks fo rthe interesting discussion. I'll create a thread on list right now (unless someone else would prefer to do it)
  231. Zash Thanks Sam, please do 🙂
  232. jonas’ Yes, please go ahead
  233. Ge0rG is commenting on the 313 LC
  234. Ge0rG but that might not cover all points.
  235. 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.
  236. Zash That sounds like a thing I should have done too
  237. Ge0rG Zash: it's not too late.
  238. Zash Didn't I reply already?
  239. Ge0rG Zash: sure, but you can reply to yourself
  240. Zash :O
  241. pprrks has left
  242. Sam Sent.
  243. pprrks has joined
  244. Kev Might it make sense to simply write a new XEP containing that one iq from 13?
  245. Kev Anyway, moved beyond Council now, I’ll take it to list.
  246. Ge0rG Kev: ...and call it 0013.
  247. Zash XEP-1300
  248. Kev Stripping a small part of a spec out into another spec is not without precedent.
  249. Ge0rG Why not removing all the unneeded parts of 0013?
  250. 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.
  251. 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?
  252. Sam But I don't really care either way.
  253. jonas’ my argument against removing '13 is how indiscoverable old XEP versions are
  254. 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
  255. daniel If we externalize it I'd really like to include the conditional part
  256. Sam jonas’ if we mark 13 as superseded by whatever the new thing is, wouldn't that add a link and make it easier?
  257. Ge0rG has left
  258. Kev daniel: “the conditional part”?
  259. daniel Purge only if mam preference is set to always
  260. Zash jonas’, for the general version discovery problem, could the xep xslt be tweaked to link to the attic?
  261. daniel Or at least not to never
  262. daniel Then I don't have to do the conditional part on the client side
  263. daniel This would allow me to properly pipe line it
  264. Ge0rG has joined
  265. Wojtek has joined
  266. B has left
  267. B has joined
  268. Tobias has left
  269. Tobias has joined
  270. Ge0rG daniel: that's an excellent suggestion, except when offline history goes longer than MAM
  271. 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.
  272. 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
  273. 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.
  274. B has left
  275. Ge0rG Kev: yeah, we are kludging workarounds for workaround for designs from twenty years ago
  276. 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.
  277. Sam Maybe I'll add a "Towards XMPP 2.0" roundtable discussions to office hours for the week afte rnext
  278. B has joined
  279. 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.
  280. 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.
  281. 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
  282. 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
  283. 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.
  284. Zash looks out over the remaining snow
  285. Sam Ge0rG: a demo of yax.im (or new features in yax.im or whatever) might be good
  286. Ge0rG is standing in the queue at the ice dealer
  287. Ge0rG ...wearing a t-shirt
  288. Sam But also that what's wrong with xmpp talk would be a good one
  289. Ge0rG I'd probably break out in tears because so little changed since 2017
  290. Sam That would make a great presentation! You could win an Oscar!
  291. Ge0rG Well, MattJ has done much better work on easy invitations than what I pioneered in yaxim back then
  292. Sam That would still be a great thing to demo, even if you didn't write it.
  293. paul has left
  294. paul has joined
  295. B has left
  296. B has joined
  297. 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
  298. daniel I have thoughts
  299. Wojtek has left
  300. dwd has left
  301. mdosch has left
  302. mdosch has joined
  303. Tobias has left
  304. Tobias has joined
  305. B has left
  306. B has joined
  307. Tobias has left
  308. Kev has left
  309. Kev has joined
  310. Kev has left
  311. Kev has joined
  312. Lance has left
  313. Kev has left
  314. Kev has joined
  315. Lance has joined
  316. Kev has left
  317. Kev has joined
  318. Kev has left
  319. Kev has joined
  320. debacle has left
  321. Syndace has left
  322. Syndace has joined
  323. paul has left