XMPP Council - 2020-01-02

  1. paul has left

  2. debacle has left

  3. daniel has left

  4. daniel has joined

  5. daniel has left

  6. daniel has joined

  7. daniel has left

  8. daniel has joined

  9. daniel has left

  10. daniel has joined

  11. beta has left

  12. beta has joined

  13. daniel has left

  14. daniel has joined

  15. daniel has left

  16. daniel has joined

  17. daniel has left

  18. daniel has joined

  19. daniel has left

  20. daniel has joined

  21. daniel has left

  22. daniel has joined

  23. daniel has left

  24. daniel has joined

  25. beta has left

  26. paul has joined

  27. beta has joined

  28. beta has left

  29. Tobias has joined

  30. daniel has left

  31. beta has joined

  32. beta has left

  33. beta has joined

  34. daniel has joined

  35. beta has left

  36. beta has joined

  37. sonny has joined

  38. larma has left

  39. undefined has left

  40. larma has joined

  41. undefined has joined

  42. beta has left

  43. beta has joined

  44. beta has left

  45. beta has joined

  46. debacle has joined

  47. sonny has left

  48. undefined has left

  49. Syndace has left

  50. Wojtek has joined

  51. Syndace has joined

  52. debacle has left

  53. undefined has joined

  54. debacle has joined

  55. daniel has left

  56. daniel has joined

  57. daniel has left

  58. daniel has joined

  59. sonny has joined

  60. undefined has left

  61. undefined has joined

  62. daniel has left

  63. susmit88 has left

  64. susmit88 has joined

  65. daniel has joined

  66. jonas’

    quick reminder that we have a council meeting today

  67. jonas’

    I forgot to send an angeda tho, and I won’t get around to do so before the meeting starts

  68. jonas’

    I’m sure you all noticed the amount of ProtoXEPs we have

  69. daniel has left

  70. daniel has joined

  71. daniel has left

  72. daniel has joined

  73. daniel has left

  74. daniel has joined

  75. Zash has left

  76. Zash has joined

  77. daniel has left

  78. daniel has joined

  79. daniel has left

  80. daniel has joined

  81. daniel has left

  82. susmit88 has left

  83. daniel has joined

  84. jonas’ summons Ge0rG, dwd, Kev, and Zash

  85. Zash


  86. jonas’

    1) Roll call

  87. jonas’

    I saw Ge0rG just now in the other room

  88. daniel


  89. jonas’

    ha, right, why am I summoning Kev

  90. jonas’

    we need daniel instead!

  91. jonas’

    anyone else, Ge0rG?

  92. dwd


  93. jonas’

    (I’m compoisng the agenda bashing section while we’re waiting)

  94. jonas’


  95. jonas’

    2) Agenda Bashing - Protoposed XMPP Extension: MAM Fastening Collation https://xmpp.org/extensions/inbox/mamfc.html - Proposed XMPP Extension: User-Defined Data Transfer https://xmpp.org/extensions/inbox/udt.html - Proposed XMPP Extension: Fallback Indication https://xmpp.org/extensions/inbox/fallback.html - Get rid of XEP-0384 (from dwd)

  96. jonas’

    anything I missed?

  97. jonas’

    I’d like to move the XEP-0384 thing to next week because I missed sending out an official agenda beforehands and it’s very controversial.

  98. jonas’

    (at least outside Council)

  99. jonas’

    and I’d like us not to appear like doing anything behind closed doors on that matter

  100. dwd

    I'd like to discuss it, even if we don't vote.

  101. jonas’

    we can certainly do that

  102. jonas’

    (ge0rg sent apologies in the other room)

  103. dwd

    It's not 100% clear what to vote on right now anyway.

  104. jonas’

    that, too

  105. jonas’

    okay, moving on

  106. jonas’

    3) Items for a Vote

  107. jonas’

    3a) Protoposed XMPP Extension: MAM Fastening Collation

  108. jonas’


  109. daniel

    on list

  110. jonas’

    Haven’t gotten around to read it yet, on-list

  111. Zash

    on list, haven't read all of it yet

  112. dwd

    I am +1, predictably.

  113. jonas’

    that’s it then

  114. jonas’

    3b) Proposed XMPP Extension: User-Defined Data Transfer URL: https://xmpp.org/extensions/inbox/udt.html

  115. jonas’

    I’m +1 in the current state

  116. jonas’

    I’m -0 in the current state

  117. jonas’

    I think valid points were made on-list about the integration of an API description in a Standards Track XEP

  118. daniel

    i usually try not to -1 xeps; but i'm really unsure that one "fills a gap in xmpp"

  119. Ge0rG

    I'm sorry, I'm in a meeting and can't really

  120. Ge0rG


  121. jonas’

    dwd, AFAICT, you did not comment on the API/Protocol mingling in the document on-list, what’s your stance on that?

  122. daniel

    i think i'm gonna -0 because i don’t want to block

  123. dwd

    I'm confident it is useful, but only if I can actually get the buy-in from the library developers.

  124. daniel

    i'm confident that if we can get buy in from library developers we can make it work without that xep

  125. daniel

    by just making extension development super easy

  126. jonas’

    daniel, but if multiple libraries support it, I’d say it should be a XEP

  127. jonas’

    ah, that

  128. dwd

    But FWIW, I'm expecting at least one high-profile XMPP use case dropped because of a lackof a simple way to exchange blobs of JSON.

  129. Zash

    Mandating an API is kinda weird. Having it as a strongly worded implementation note is probably fine tho?

  130. jonas’

    dwd, what’s your stance on splitting of the API description in an Informational document?

  131. dwd

    In fairness, it doesn't need an API as much as consistent terminology in the API.

  132. dwd

    jonas’, Honestly I'd go for dropping the API entirely, and just go for an implementation note on terminology.

  133. daniel

    i mean i have seen people put things in bodies too (haven’t seen the subject content-type thing yet; but whatever) - but that is better solved by communicating what xmpp actually is

  134. jonas’

    daniel, I liked dwds point about "If someone is reading our communication in form of specs, they’re not the target audience."

  135. jonas’

    dwd, alright, I guess that’d work too

  136. daniel

    communicating what xmpp is would also somewhat fix the "but the XSF doesn’t provide a xep for use case x"

  137. pep.

    (I'd also prefer to push for documentation)

  138. dwd

    daniel, I think the content-type in subject was a better option than most, yes. But if everyone's doing the <body/> thing I'd feel happier we had some kind of technical approach for it.

  139. dwd

    And as I say, nobody's reading our documentation now except the library authors, so...

  140. jonas’

    I mean, there’s already the JSON Container XEP, but libraries don’t have API for simply throwing a JSON in a message typically, I guess.

  141. jonas’

    and I think the protoxep at hand adding the type field is a nice touch which is essentially for interop

  142. jonas’

    I think this XEP allows libraries to reduce the entry hurdle a lot by providing a simple "fire this JSON" API

  143. daniel

    can we at the very least not define it for IQs

  144. dwd

    daniel, Sure.

  145. daniel

    if you are at the level of doing IQs just read up on what xmpp is

  146. dwd

    daniel, I mean, people will write a REST-a-like in <message/> containing UDT, but that's still less awful that what they're doing now.

  147. jonas’

    daniel, good point

  148. jonas’

    dwd, and I doubt that kind of people would use the IQ interface of UDT

  149. jonas’

    another good point about this is that library docs can clearly state: "You can use JSON here, but if you have a more complex usecase than just routing some JSOn data through XMPP, you should read up on our docs on developing your own extension [link]."

  150. jonas’

    which is an entry point into getting people into knowing what XMPP is

  151. dwd

    Oh, for sure.

  152. jonas’

    and how to work with it

  153. jonas’

    so to summarise, the TODO for this XEP would be: - Remove the IQ usecase - Change the wording around the API

  154. jonas’

    I’d be +1 with those changes

  155. jonas’

    (if reasonably executed, of course)

  156. dwd

    And I can just change it back afterward, right?

  157. daniel

    ok; should we move on?

  158. jonas’

    dwd, :P

  159. daniel

    if we still want to discuss omemo; and make the 30min

  160. jonas’

    if nobody else has anything, let’s move on indeed

  161. Zash

    I'll just go ahead and +1

  162. jonas’

    3c) Proposed XMPP Extension: Fallback Indication URL: https://xmpp.org/extensions/inbox/fallback.html

  163. jonas’

    so when I commented on-list, I got confused about this one

  164. daniel

    on list

  165. jonas’

    but I’m also going to be on-list

  166. jonas’

    I can’t form an ad-hoc opinion about this vs. hints

  167. dwd

    I am +0 on this. In many ways I think this might be better as a hint, but we need to revisit why that was rejected. There were remediations discussed for hints, but not in detail, so I don't know what we can do there.

  168. Zash

    on list. (hints was rejected?)

  169. jonas’


  170. dwd

    Zash, No, it wasn't actually. It was bumped back to Experimental, Sam Whited explicitly rejected no-copy, and there was some discussion about a fix or two.

  171. jonas’

    3d) Most Likely Not For A Vote: Reject XEP-0384 OMEMO (in whatever way)

  172. dwd

    I've now been told definitively by different people that OMEMO both can, has, and cannot be implemented without the GPL libsignal.

  173. jonas’

    I think dwds argument is sound

  174. jonas’

    all implementations I know of either use libsignal or are GPL out of fear of libsignal

  175. daniel

    i'm +1 (because it is actually a bad standard); but i'm wondering if we should release a blog post or something to explain what that means/what it doesn’t mean

  176. jonas’

    daniel, good idea

  177. dwd

    Whatever the truth is (and I think the truth is important), it ought to be deferred, which is going to cause confusion.

  178. dwd

    Of course, none of this should mean people don't use and even implement it.

  179. jonas’

    daniel, this may sound evil loadpushingly, but since you’re a strong proponent of E2EE in general (or are at least percieved in such a way with Conversations), would you take that on?

  180. Zash

    So can you or can't you implement it?

  181. jonas’

    Zash, you can, the question is whether it’s legal ;)

  182. jonas’

    and the next question is whether a judge would rule in favour of you in juryland

  183. daniel

    jonas’, i guess…

  184. larma

    I suggest we have SIG-E2EE work over it to make it not say you that it's required to use libsignal (if that is said anywhere) and instead document enough so that one can (with external references) implement it from XEP.

  185. Zash

    I am not a laywer and what is this?

  186. dwd

    Zash, Without libsignal? Sam and larma insist you can. Moxie thinks you aren't allowed last I looked. Philip says it's impossble without using the library.

  187. pep.

    Btw, shouldn't the SIG-E2EE be on the agenda as well? It's up to council right? ("A Special Interest Group (SIG) is a working group approved by the XMPP Council")

  188. dwd

    pep., Marked as Board. Honestly I just assumed it was a Board thing.

  189. Zash

    I'm not that fond of other parts of the XEP either, e.g. the PEP bits are weird.

  190. larma

    dwd, I haven't seen this message by Philip so I can't comment on that, maybe there was some misunderstanding?

  191. jonas’

    dwd, and Syndace successfully implemented it without directly depending on libsignal (but the wire format plugin for libsignal-compat is still GPL)

  192. jonas’

    pep., oh, I also assumed SIGs are a Board topic

  193. daniel

    > Moxie thinks you aren't allowed last I looked. independently of whether or not a XEP should contain "use libsignal" (it shouldn’t) i wouldn’t trust a word that guy says

  194. jonas’

    daniel, doesn’t help if he’s willing to sue over it, and to be honest, this whole mess looks grey-area-like enough that you’ll probably lose in the first instance and spend lots of money in court.

  195. dwd

    daniel, Sure, but in this case he paid lawyers a lot of money to say the same thing.

  196. jonas’

    (pep., where did you get that SIG quote from?)

  197. jonas’

    okay, we’re close to our limit, I’d like to move on

  198. jonas’

    4) Date of next

  199. jonas’

    Wed, 2020-01-08 16:00Z here?

  200. dwd

    jonas’, XEP-0002 I assume.

  201. dwd

    jonas’, +1 to next week.

  202. Zash


  203. pep.

    002 yes

  204. jonas’

    dwd, indeed, going to put it on next weeks agenda then, and fix the XEP

  205. daniel

    Wed is fine with me

  206. jonas’

    5) AOB

  207. jonas’

    we’re out of time, except for quick announcements

  208. jonas’

    does anyone have anything?

  209. daniel


  210. jonas’

    6) Ite, Meeting Est

  211. jonas’

    Thanks all

  212. dwd

    As a heads-up, I'll try and have an Inbox spec done by the end of tomorrow and submitted as a ProtoXEP.

  213. jonas’

    dwd, okay, if this is your activity peak BEFORE FOSDEM, then I’m scared what will come after ;)

  214. pep.

    "larma> dwd, I haven't seen this message by Philip" < it was part of the thread I forked from.

  215. pep.

    (I tried to include stuff from it to keep a bit of context)

  216. dwd

    Well, I've some ideas on FOSDEM and output.

  217. dwd

    Most particularly, I think anytime we do "new" work at the Summit, it generally results in a lot of noise and little outcome. So I'm trying to put the effort into concrete specs beforehand so we can discuss known open issues instead of trying to create something entirely new.

  218. jonas’

    I think that’s sound

  219. dwd


  220. daniel has left

  221. daniel has joined

  222. hichamel has joined

  223. hichamel


  224. dwd

    Spam in the Council room?

  225. Zash

    It's more likely than you think

  226. undefined has left

  227. dwd

    Oh. I didn't vote on 3b). I'm +1 with jonas’ proposed changes, which I'll get onto now.

  228. jonas’

    I’m not recording your vote on that in the spreadsheet of doom yet, then

  229. undefined has joined

  230. hichamel has left

  231. daniel has left

  232. stpeter has joined

  233. daniel has joined

  234. flow

    daniel> i think i'm gonna -0 because i don’t want to block I always wonder if '0'ing a ProtoXEP is not just the same as blocking it, after all, IIRC ProtoXEPs need a majority of +1s to get accepted. Or am I wrong?

  235. jonas’

    flow, it’s not blocking, because a -1 is a VETO

  236. jonas’

    while a ±0 can still pass if there is a majority of +1 (as you note), something which got a single -1 cannot ever pass

  237. jonas’

    while a ±0 can still pass if there is a majority of +1 (as you note), something which got a single -1 cannot pass

  238. flow

    right, but if everyone did vote '0', then the XEP will not be accepted, and then I wouldn't say that the 0-voters did not block the XEP

  239. jonas’

    that’s true

  240. flow

    or how can it be that nobody blocked a XEP and it still gets not accepted

  241. jonas’

    they were partially-blocking

  242. jonas’

    which makes sense

  243. Zash

    Negative parlamentarism is kinda neat.

  244. daniel

    well if you vote -1 it will get blocked immediately. if I vote +/- 0 it will only get blocked if there are not enough people in favor

  245. daniel

    which makes sense

  246. daniel

    to me

  247. flow

    daniel, the issue I see is that even if you have 4x '0' and 1x '+1', then it won't get accepted

  248. flow

    so I wonder if we should lower the bar for experimental by only requireing the sum of the votes to be positive

  249. daniel

    > daniel, the issue I see is that even if you have 4x '0' and 1x '+1', then it won't get accepted Yes. That was the intention. Because if that's the case 4 people find it problematic in a way or another

  250. flow

    Sure, be we are still talking about accepting a ProtoXEP as experimental

  251. daniel

    I think our consensus is currently going in a 'super inbox' direction

  252. daniel

    For the catch all no bar xeps

  253. flow

    Well hopefully this leads to us putting less effort in rejecting xeps and more effort into improving existing ones

  254. flow

    And I hope nobody here takes this personal, I see that dwd's xep can be viewed as borderline, but he has some valid points and I don't see any harm in it becoming experimental

  255. dwd

    flow, Which XEP is borderlne?

  256. dwd

    flow, I see one as borderline, one leaning toward adoption, and one an easy accept. Of course, my views aren't an absolute for Council to follow. :-)

  257. Zash

    but which is which?

  258. jonas’

    my guess: fallback is borderline, easy accept is UDT

  259. flow

    dwd, btw, Smack has an API which can be considered similar to UDT since ~20 years, it's called jiveproperties

  260. debacle has left

  261. Wojtek has left

  262. debacle has joined

  263. stpeter has left

  264. Neustradamus has left

  265. stpeter has joined

  266. debacle has left

  267. daniel has left

  268. daniel has joined

  269. Neustradamus has joined

  270. beta has left

  271. beta has joined

  272. Tobias has left

  273. sonny has left

  274. sonny has joined

  275. sonny has left

  276. sonny has joined

  277. dwd

    jonas’, Nope.

  278. dwd

    jonas’, For me, MAMFC is the easy one to accept. It's complex, and will need changes, but it's a solid start to a problem that needs solving.

  279. debacle has joined

  280. sonny has left

  281. undefined has left

  282. undefined has joined

  283. dwd

    jonas’, You were right with fallback, though - it's unclear if it's the correct solution, although it might be the only one given No Hints.

  284. paul has left

  285. beta has left

  286. beta has joined

  287. beta has left

  288. beta has joined

  289. beta has left

  290. beta has joined

  291. beta has left