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 Here
  86. jonas’ 1) Roll call
  87. jonas’ I saw Ge0rG just now in the other room
  88. daniel hi
  89. jonas’ ha, right, why am I summoning Kev
  90. jonas’ we need daniel instead!
  91. jonas’ anyone else, Ge0rG?
  92. dwd Hello.
  93. jonas’ (I’m compoisng the agenda bashing section while we’re waiting)
  94. jonas’ alright
  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’ https://xmpp.org/extensions/inbox/mamfc.html
  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 focus.
  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’ okay
  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 +1
  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 no
  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 Maybe.
  220. daniel has left
  221. daniel has joined
  222. hichamel has joined
  223. hichamel https://bit.ly/35n0oOY
  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