XMPP Council - 2021-04-21

  1. Zash has joined

  2. Kev has left

  3. Kev has joined

  4. stpeter has left

  5. SouL has left

  6. stpeter has joined

  7. Kev has left

  8. Kev has joined

  9. stpeter has left

  10. Kev has left

  11. Kev has joined

  12. Kev has left

  13. Kev has joined

  14. Kev has left

  15. Kev has joined

  16. Kev has left

  17. SouL has joined

  18. stpeter has joined

  19. Tobias has joined

  20. stpeter has left

  21. paul has joined

  22. Zash has left

  23. Zash has joined

  24. Kev has joined

  25. Kev has left

  26. Kev has joined

  27. debacle has joined

  28. mdosch has left

  29. mdosch has joined

  30. sonny has left

  31. sonny has joined

  32. sonny has left

  33. sonny has joined

  34. moparisthebest has left

  35. sonny has left

  36. sonny has joined

  37. moparisthebest has joined

  38. sonny has left

  39. sonny has joined

  40. vaulor has left

  41. vaulor has joined

  42. Guus has left

  43. Wojtek has joined

  44. Guus has joined

  45. Guus has left

  46. vaulor has left

  47. vaulor has joined

  48. Syndace has left

  49. Syndace has joined

  50. stpeter has joined

  51. Syndace has left

  52. Syndace has joined

  53. stpeter has left

  54. stpeter has joined

  55. Syndace has left

  56. Syndace has joined

  57. jonas’

    1) Roll Call

  58. Zash here

  59. jonas’

  60. daniel


  61. Ge0rG

  62. jonas’

    no dwd?

  63. jonas’

    2) Agenda Bashing

  64. jonas’


  65. jonas’

    3) Editor’s Update

  66. jonas’

    nothing unusual

  67. jonas’

    4) Items for Voting

  68. jonas’

    No new items

  69. jonas’

    5) Pending Votes

  70. jonas’

    we need to handle the LCs now

  71. Zash

    Carbons and MAM eh

  72. jonas’


  73. Kev

    I think MAM needs at least one round of changes, given my review yesterday, but they’re not major.

  74. Kev

    (Jumping ahead because I might not notice when (5) comes up)

  75. Ge0rG

    I think MAM needs at least one round of changes, given my review three weeks ago, but they're rather significant.

  76. jonas’

    Kev, we are already at (5) :)

  77. dwd

    Ah. Sorry, I've been dragged into a meeting.

  78. Zash

    I've looked at past LCs and there's been a lot of back and forth on things

  79. Ge0rG

    The agenda items 2 to 5 all arrived in the same second at my end. Some lag might be involved.

  80. Zash

    <private> vs xep-0334 and whatnot

  81. Ge0rG

    Should we have some separate discussion of the open points of 0280 and of 0313 before casting final votes?

  82. Ge0rG` has joined

  83. jonas’

    so IMO we should factor out the rules in a standards track document which defines disco#info features. The rules should be called "general routing rules" and versioning should go across all of them, but they may be different for the different "routing" protocols (MAM, Carbons, CSI, Push…)

  84. Zash

    Sounds good.

  85. jonas’

    we can think about the issue that such a living document can never advance beyond Draft later.

  86. Ge0rG

    jonas’: so one namespace for all the routing rules, instead of one namespace per task?

  87. jonas’

    ideally that issue resolves itself with IM-NG

  88. jonas’

    Ge0rG, yes

  89. jonas’

    but I’m not hard-sold on that

  90. Zash

    The base wire protocols are probably good enough and certainly well-deployed by now,..

  91. jonas’

    Zash, exactly

  92. Ge0rG

    What do we do with urn:xmpp:carbons:rules:0?

  93. jonas’

    Ge0rG, make it implicit in urn:xmpp:routing-rules:0

  94. jonas’

    and advertise it for up to routing-rules:N, where N is the revision where the rules for carbons are first changed

  95. Kev

    FWIW, nothing needs factoring out of either 313 or 280 in order for later rules to be defined elsewhere.

  96. Ge0rG

    well, the feature version was just a quirk to get around bumping carbons, so I'm not fighting to death over it

  97. Kev

    (At least, the intention when writing the text in 313 was that a later external feature could be advertised for a concrete set of rules, same as 280)

  98. jonas’

    but again, not hard sold on unifying them; it seemed sensible to me on a quick thought to have that all under a single version umbrella, but especially when we have to adapt (e.g. only) push rules and then have to forklift all features, it seems a bit overkill

  99. jonas’

    yep, separated features are probably waaay better

  100. Zash

    And then compliance suites that point to recommended versions?

  101. Ge0rG

    I'm torn on whether to use my 0313 vote to extort somebody to write down those rules for 0313

  102. jonas’

    Zash, yes

  103. jonas’

    Ge0rG, I get the impression that '313 may be blocked anyway

  104. Kev

    I don’t think 313 is blocked otherwise in a meaningful sense. I.e. I don’t think any changes need another LC.

  105. Ge0rG

    Indeed, even if I were to retract my storage rules requirement, there are still the open questions around MUC in personal MAM and client business rules

  106. Ge0rG

    and of course the bind2 / MAM subscription topic that probably needs to be postponed anyway.

  107. Zash

    Myeah, recommending against storing MUC messages without additional negotiation would probably be good.

  108. Zash

    "additional negotiation" something something MIX I guess

  109. Ge0rG

    against *delivering*

  110. Ge0rG

    backfilling of MIX history on the personal MAM is still an unsolved problem.

  111. Ge0rG

    Given that, I'm solidly -1 on 0313.

  112. jonas’


  113. jonas’

    how about '280?

  114. Zash

    The <private> thing seems unresolved.

  115. Ge0rG

    Kev addressed the "stripping <private> parts" point and I'd like to get a discussion of Hints

  116. Ge0rG

    My desired way forward would be to remove the stripping requirement, to completely remove Hints, and to Convince Council to go on without a namespace bump.

  117. daniel

    you'd need to convince the authors. not council

  118. Ge0rG

    I'd also rewrite the Mobile Considerations to say the opposite of what it does now, but that's the non-normative part.

  119. Syndace has left

  120. Syndace has joined

  121. Ge0rG

    daniel: given that I'm one of the authors, you can consider it done.

  122. jonas’

    my problem with not bumping the namespace there would be, on a theoretical level, that a client relying on <private/> not being stripped may be owned in one way or another by an old server

  123. Ge0rG

    Still, I've heard some objections from Council members about this suggestion last week

  124. Zash

    Does anything really bad happen in that case?

  125. Ge0rG

    jonas’: you mean by a client relying on <private/> *being* stripped?

  126. jonas’

    Ge0rG, no

  127. Ge0rG

    jonas’: ah, now I get you

  128. jonas’

    if we don’t bump and a new implementation comes along, relying for $importantFeature on <private/> being there, it will be confused when <private/> is *not* there because the server is on old carbons

  129. Ge0rG

    So I'd also add an implementation note.

  130. jonas’

    and then what?

  131. Ge0rG

    jonas’: also there used to be different semantics for stripping <private/> before 2013, https://xmpp.org/extensions/xep-0280.html#revision-history-v0.9

  132. Kev


  133. Kev

    Is that a pragmatic compromise?

  134. Zash

    Would work I guess?

  135. jonas’

    Kev, would’ve been my next suggestion :)

  136. dwd

    Not a valid URN?

  137. Zash


  138. jonas’

    Ge0rG, wait what

  139. Kev

    It’s in pre-encoded form.

  140. jonas’

    it was changed again?

  141. jonas’

    it was changed already back and forth?

  142. Ge0rG

    jonas’: as I read the log, it was stripped by the *sending* server before

  143. Zash

    <server author hat> I think it does that still?

  144. jonas’


  145. Zash

    or what

  146. jonas’


  147. jonas’

    that makes me think that we should not at all rely on <private/> being there or not being there

  148. jonas’

    too many versions

  149. jonas’

    and adding another change is not going to make it any better

  150. Ge0rG

    So can I move forward with my grand plan?

  151. jonas’

    Ge0rG, no, I think that you should leave <private/> alone

  152. Ge0rG

    jonas’: is that an opinion or a foreshadowed Council vote?

  153. jonas’

    that is an opinion

  154. jonas’

    because I don’t see what good it brings

  155. Ge0rG`

    Sorry, my prosody is stalled

  156. jonas’

    I hope this wasn’t me

  157. Ge0rG`

    Only if you suddenly took over VaxBot

  158. Ge0rG

    jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.

  159. Kev

    I think it’s a not-insignificant security consideration to strip private.

  160. Ge0rG`

    > jonas’: I think that Kev has a great point about letting the receiving client know that it received a Carbon that won't get delivered to any other resource.

  161. Kev

    Letting another user modify my server’s routing rules without telling me does not seem at all safe.

  162. jonas’

    Kev, I agree, but just removing that rule doesn’t mean that anyone can rely on it

  163. Kev

    Thus feature.

  164. jonas’

    Ge0rG`, so you could do it with a feature flag IMO

  165. Kev

    But this isn’t a case of clients relying on it.

  166. Kev

    It’s a case of a user of a server relying on the server not doing questionable things without trace.

  167. Ge0rG`

    But we are also still in Experimental, so it's all not so bad from a protocol point of view. Right?

  168. Ge0rG`

    (from a Council protocol...)

  169. jonas’

    Ge0rG`, yes

  170. Kev

    I would be ok (not that my opinion matters) with removing that (or rather, flipping that to a must not) rule without adding the feature. But adding the feature is cheap, and not without value, so why not.

  171. jonas’

    what Kev says tho

  172. Ge0rG

    Alright, I can live with what Kev says.

  173. jonas’

    then do that please

  174. Ge0rG

    Now what about stripping Hints from the XEP?

  175. jonas’

    do we know how widely implementations rely on that?

  176. Zash

    Do we not like Hints anymore?

  177. Ge0rG

    Ironically, current-0280 requires to strip <private/> but doesn't mention strpping the Hint.

  178. Kev

    I would probably form an opinion on that given time to think, but don’t currently have one on the hop.

  179. jonas’

    Ge0rG, what is the harm of keeping it?

  180. Ge0rG

    jonas’: we are enshrining a protocol that we don't want to keep.

  181. Zash

    We don't?

  182. Ge0rG

    jonas’: there was a version of 0280 that only required adding <private/> and later a version that required adding both <private/> and the Hint.

  183. Ge0rG

    Thus, removing the Hint requirement won't break any compliant implementations.

  184. Ge0rG

    I dislike the inconsistency of https://xmpp.org/extensions/xep-0280.html#avoiding

  185. jonas’

    section 9 reads very confusing

  186. jonas’

    > The sending client MAY exclude a <message/> from being forwarded to other Carbons-enabled resources, by adding a <private/> element qualified by the namespace "urn:xmpp:carbons:2" and a <no-copy/> hint as described in Message Processing Hints (XEP-0334) [8] as child elements of the <message/> stanza.

  187. jonas’

    the sending client is not excluding anything, protocol wise

  188. jonas’

    and then the enumeration just goes on as if it was on the same side of the contract ... very weird

  189. jonas’

    Ge0rG, put that on your list of things to fix please

  190. Ge0rG

    jonas’: I'd improve the wording while removing Hints.

  191. jonas’


  192. jonas’

    if *both* are currently required, we can remove hints without damage indeed

  193. Ge0rG

    jonas’: that's what the XEP says, right?

  194. jonas’


  195. jonas’

    I think

  196. jonas’

    I mean I think the XEP makes no statement at all about that in the text as written because of that wording weirdness, but the intent is clear

  197. Ge0rG

    Yes, that's also my reading of it

  198. daniel

    The concept of private messages is out dated anyway. I think a variant version of carbons todo wouldn't even have it

  199. Ge0rG

    daniel: what about OTR?

  200. daniel


  201. jonas’

    "out dated"

  202. daniel

    My point exactly

  203. Kev

    Private goes away in IMNG, I think, but I’m not sure until then.

  204. daniel

    Otr was the only thing that used it

  205. Ge0rG

    Kev: but it goes away because we introduce a different mechanism to route a message just to a single specific resource, right?

  206. daniel

    And even otrv3 technically didn't event need it

  207. Kev

    Ge0rG: Right.

  208. Ge0rG

    So just the XML element goes away, not the semantics.

  209. Kev

    The new syntax for sending just to one resource becomes to=‘fulljid’ :D

  210. Ge0rG

    Unless we decide that we do not have any more need to route messages just to a single resource.

  211. jonas’


  212. jonas’

    we’re a bit over time at this point

  213. jonas’

    Ge0rG, do you need any further input?

  214. Ge0rG

    But I'm pretty sure we will have some use for that in IOT or PubSub events

  215. Ge0rG

    jonas’: no.

  216. jonas’


  217. jonas’

    6) Date of Next

  218. jonas’

    +1w wfm

  219. Ge0rG

    Is the CVE PR applied already? :D

  220. jonas’

    (waking up Zash and dwd )

  221. daniel

    +1w wfm

  222. Zash

    +1w wfm

  223. Ge0rG

    +1W WFM, but the following two weeks I'm going to be on vacation (from the computer screen)

  224. jonas’

    Ge0rG, good for you!

  225. jonas’

    7) AOB

  226. jonas’

    skipped because time

  227. jonas’

    8) Ite Meeting Est

  228. Ge0rG

    But but but AOB!

  229. Zash

    no aob for you

  230. jonas’

    Ge0rG, no, not yet, please bring it to the list because there was controversy around that in xsf@ and I’d like to have some rough consensus

  231. Ge0rG

    Also nobody cast their votes on 0280

  232. jonas’

    Thanks everyone

  233. Ge0rG

    so this makes another failed LC, right?

  234. jonas’

    Ge0rG, right, forgot, I wanted to ask

  235. jonas’

    9) Ite Meeting Un-Est

  236. jonas’

    votes on '280?

  237. jonas’

    I imagine you’ll want to veto

  238. daniel


  239. Ge0rG

    +1 with all the discussed changes applied.

  240. Zash

    -1 until the <private> thing has consensus and is resolved

  241. jonas’

    following Zash here

  242. jonas’

    (changing my +1)

  243. Ge0rG

    Zash: how do you imagine consensus happening here?

  244. daniel

    I don't think it matters what label we put on a very flawed but de facto draft xep

  245. jonas’

    10) Ite Meeting Est for real

  246. jonas’

    Thanks everyone

  247. jonas’

    (gotta run, need to prepare for being reaallly quick in 15 minutes)

  248. Zash

    Ge0rG: apply the changes discussed. I've ran out of coffee, can't think anymore.

  249. Ge0rG

    Alright. I'll PR and then ask for another LC.

  250. Zash

    and ... '313 is ..?

  251. jonas’


  252. Ge0rG

    Zash: vetoed by me

  253. Zash


  254. Ge0rG

    I've been naughty.

  255. Zash

    Very well then

  256. pprrks has left

  257. Syndace has left

  258. Syndace has joined

  259. Guus has joined

  260. Lance has joined

  261. Lance has left

  262. sonny has left

  263. sonny has joined

  264. Guus has left

  265. Ge0rG` has left

  266. Ge0rG` has joined

  267. SouL has left

  268. SouL has joined

  269. Ge0rG` has left

  270. Ge0rG` has joined

  271. Wojtek has left

  272. SouL has left

  273. Ge0rG` has left

  274. Ge0rG` has joined

  275. SouL has joined

  276. Ge0rG` has left

  277. Ge0rG` has joined

  278. Ge0rG` has left

  279. Ge0rG` has joined

  280. Ge0rG` has left

  281. Ge0rG` has joined

  282. Ge0rG` has left

  283. Ge0rG` has joined

  284. Ge0rG` has left

  285. Ge0rG` has joined

  286. Ge0rG` has left

  287. Ge0rG` has joined

  288. Syndace has left

  289. Syndace has joined

  290. Ge0rG` has left

  291. Ge0rG` has joined

  292. Syndace has left

  293. Syndace has joined

  294. Lance has joined

  295. Ge0rG` has left

  296. Ge0rG has left

  297. Ge0rG` has joined

  298. Ge0rG has joined

  299. Ge0rG` has left

  300. Ge0rG has left

  301. Ge0rG` has joined

  302. Ge0rG has joined

  303. Tobias has left

  304. Ge0rG` has left

  305. Ge0rG` has joined

  306. Ge0rG has left

  307. Ge0rG has joined

  308. Lance has left

  309. Ge0rG` has left

  310. Ge0rG` has joined

  311. Lance has joined

  312. Ge0rG` has left

  313. Ge0rG` has joined

  314. Syndace has left

  315. Syndace has joined

  316. Zash has left

  317. Syndace has left

  318. Syndace has joined

  319. Ge0rG` has left

  320. Ge0rG` has joined

  321. Lance has left

  322. Lance has joined

  323. Ge0rG` has left

  324. Ge0rG` has joined

  325. paul has left

  326. SouL has left

  327. Ge0rG` has left

  328. Ge0rG` has joined

  329. debacle has left

  330. Lance has left