XSF Discussion - 2019-06-24

  1. zach has left
  2. zach has joined
  3. pdurbin has joined
  4. lskdjf has left
  5. pdurbin has left
  6. Daniel has left
  7. Daniel has joined
  8. rtq3 has left
  9. Lance has left
  10. Lance has joined
  11. Daniel has left
  12. Daniel has joined
  13. Daniel has left
  14. neshtaxmpp has left
  15. neshtaxmpp has joined
  16. Daniel has joined
  17. pdurbin has joined
  18. alacer has joined
  19. alacer has left
  20. pdurbin has left
  21. Yagiza has joined
  22. pdurbin has joined
  23. Lance has left
  24. waqas has left
  25. Lance has joined
  26. Daniel has left
  27. Daniel has joined
  28. andy has joined
  29. sezuan has joined
  30. sezuan has left
  31. sezuan has joined
  32. krauq has left
  33. COM8 has joined
  34. COM8 has left
  35. lumi has left
  36. pdurbin has left
  37. COM8 has joined
  38. COM8 has left
  39. Daniel has left
  40. pdurbin has joined
  41. Daniel has joined
  42. sezuan has left
  43. sezuan has joined
  44. madhur.garg has joined
  45. madhur.garg has left
  46. Nekit has joined
  47. rtq3 has joined
  48. wurstsalat has left
  49. Daniel has left
  50. Daniel has joined
  51. rtq3 has left
  52. rtq3 has joined
  53. Daniel has left
  54. pdurbin has left
  55. igoose has left
  56. sezuan has left
  57. krauq has joined
  58. andy has left
  59. goffi has joined
  60. andy has joined
  61. Daniel has joined
  62. rion has left
  63. rion has joined
  64. Steve Kille has left
  65. kokonoe has left
  66. kokonoe has joined
  67. Steve Kille has joined
  68. rtq3 has left
  69. rtq3 has joined
  70. COM8 has joined
  71. COM8 has left
  72. karoshi has joined
  73. Lance has left
  74. Lance has joined
  75. sezuan has joined
  76. sezuan has left
  77. sezuan has joined
  78. Lance has left
  79. Lance has joined
  80. Lance has left
  81. Lance has joined
  82. COM8 has joined
  83. wurstsalat has joined
  84. Douglas Terabyte has left
  85. Douglas Terabyte has joined
  86. COM8 has left
  87. neshtaxmpp has left
  88. pdurbin has joined
  89. marc_ has joined
  90. pdurbin has left
  91. lnj has joined
  92. Daniel has left
  93. Daniel has joined
  94. Lance has left
  95. frainz has left
  96. frainz has joined
  97. Nekit has left
  98. Nekit has joined
  99. debacle has joined
  100. Kacper has joined
  101. zach has left
  102. zach has joined
  103. marc_ has left
  104. lskdjf has joined
  105. lskdjf has left
  106. lskdjf has joined
  107. rtq3 has left
  108. rtq3 has joined
  109. rtq3 has left
  110. debacle has left
  111. rtq3 has joined
  112. pdurbin has joined
  113. Syndace has left
  114. Syndace has joined
  115. pdurbin has left
  116. igoose has joined
  117. Kacper has left
  118. Kacper has joined
  119. pdurbin has joined
  120. igoose has left
  121. igoose has joined
  122. debacle has joined
  123. rtq3 has left
  124. pdurbin has left
  125. rtq3 has joined
  126. pdurbin has joined
  127. pdurbin has left
  128. Steve Kille has left
  129. Steve Kille has joined
  130. pdurbin has joined
  131. pdurbin has left
  132. igoose has left
  133. igoose has joined
  134. pdurbin has joined
  135. pdurbin has left
  136. igoose has left
  137. igoose has joined
  138. valo has left
  139. valo has joined
  140. igoose has left
  141. kokonoe has left
  142. kokonoe has joined
  143. marc_ has joined
  144. waqas has joined
  145. COM8 has joined
  146. COM8 has left
  147. neshtaxmpp has joined
  148. moparisthebest has left
  149. moparisthebest has joined
  150. mimi89999 has left
  151. pdurbin has joined
  152. pdurbin has left
  153. mimi89999 has joined
  154. dwd vanitasvitae, Love your SCE examples.
  155. lumi has joined
  156. vanitasvitae dwd: :D
  157. vanitasvitae Glad to hear that :P
  158. kokonoe has left
  159. kokonoe has joined
  160. Nekit has left
  161. Nekit has joined
  162. j.r has left
  163. andy has left
  164. andy has joined
  165. Lance has joined
  166. j.r has joined
  167. dwd vanitasvitae, So, my understanding of SCE is that it's not a "solution" as such, but a utility element that can be used by other e2e encryption systems?
  168. dwd For example, OMEMO would use it by dropping <payload/> and using SCE's <envelope/> in its place? But an <envelope/> on its own has no meaning.
  169. pep. yep, that's also how I picture it
  170. rtq3 has left
  171. vanitasvitae dwd: thats right
  172. vanitasvitae Encryption mechanisms would define profiles that use sce
  173. dwd That does mean that the <envelope/> itself has no definition beyond high-level syntax ("it contains CDATA"), because the content and operation of it is defined in different ways by different e2e layers.
  174. dwd I'm not sure if that's OK or not, to be honest.
  175. vanitasvitae Yep thats right
  176. pep. dwd, what do you mean it's not ok
  177. dwd pep., An element whose definition depends on the parent (containing) element seems like stretching the use of XML quite a bit.
  178. pep. I'm not sure I understand this entirely
  179. dwd Still, the <content/> concept, and some standardized rules on what goes in it, what stays out, and so on all seems sensible.
  180. pep. Isn't that what all XEPs are about?
  181. andy has left
  182. Nekit has left
  183. Nekit has joined
  184. vanitasvitae I'm also not entirely sure what you mean by stretching the use of XML 😀
  185. dwd pep., Not really. A <delay/> element has fixed semantics, and doesn't require the containing element to say what its content means.
  186. vanitasvitae ah
  187. pep. What if we add a @node or @whatever with the ns of the encryption mechanism?
  188. pep. So it doesn't need to be contained in a subelement
  189. pep. (of message)
  190. dwd pep., Even other utility elements, like <forwarded/> (which personally I felt was basically noise) can be parsed and handled without knowing what they're contained by.
  191. vanitasvitae so you are not sure about "an openpgp element INSIDE an envelope must be treated differently from a "normal" openpgp element"?
  192. dwd vanitasvitae, I'm not actually sure you need the <envelope/> element at all, given that OMEMO, OpenPGP, etc all have to define its use anyway.
  193. vanitasvitae ah got it.
  194. vanitasvitae hmm.
  195. pep. dwd, we can still have common elements
  196. dwd vanitasvitae, That's not a reason for me to block this, BTW. I don't think there's any reason to block this as far as I can see.
  197. pep. And these more specific XEPs define how these elements are used
  198. j.r has left
  199. dwd pep., What does the element tell us?
  200. pep. pad, date, etc.
  201. dwd pep., Those are in <content/> as <rpad/>, <time/>, and so on.
  202. pep. Ok let me read the thing again
  203. dwd pep., I'm totally on board with <content/>. It's <envelope/> I'm a little worried by.
  204. Lance has left
  205. vanitasvitae dwd, I definitely see what you mean. We could even save some chars by removing the encapsulating <envelope/> element.
  206. vanitasvitae I think the main reason for me was to "bundle" the sce stuff together if that makes sense.
  207. vanitasvitae Also thats the way OX does it 😀
  208. dwd vanitasvitae, I think, sa I say, that OMEMO has to define its use. Or at least, SCE could, but it's specific to each e2e mechanism.
  209. andy has joined
  210. pep. vanitasvitae, this https://geekplace.eu/xeps/xep-sce/xep-sce.html ?
  211. pep. (that's the last version?)
  212. dwd pep., https://xmpp.org/extensions/inbox/xep-sce.html
  213. pep. oh it's in the inbox now
  214. vanitasvitae pep., it made its way into the inbox 😀
  215. dwd pep., Hence I'm reading it. :-)
  216. vanitasvitae 😀
  217. vanitasvitae so basically we could get rid of <envelope/> and let the encryption mechanisms replace their <payload/> or whatever payload element they use by <sce:content/>.
  218. vanitasvitae sounds sensible for now
  219. pep. vanitasvitae, I don't think you should be using eu.siacs.conversations.axolotl as a example ns btw
  220. pep. Though technically there's nothing that prevents it..
  221. vanitasvitae so for OMEMO we would have <encrypted> <header>...</header> <content> <rpad etc./> <payload>...</payload> </content> </encrypted>
  222. Zash Doesn't the namespace have to be an URI?
  223. COM8 has joined
  224. COM8 has left
  225. pep. Zash, I meant, if that's the current OMEMO ns, nothing actually prevents reusing it and shoving more stuff in it
  226. pep. vanitasvitae, right, and then in this case <payload> is conflicting and we need to change the NS :p
  227. vanitasvitae ah no wait, I messed up my example. <encrypted> <header>...</header> <payload> (here be encrypted <content/>) </payload> </encrypted>
  228. Nekit has left
  229. pep. dwd, I get your point now. I also don't think it hurts
  230. pep. I also don't know all encryption mechanisms out there, maybe that won't work for one..
  231. Nekit has joined
  232. rtq3 has joined
  233. vanitasvitae hehe, going with <envelope/> would maybe allow for a transition period *duck*
  234. pep. What about the multi-recipient case, can just one <envelope/> tag be used for this?
  235. pep. https://op-co.de/tmp/SEX.html something à la <multibox/> here
  236. vanitasvitae I haven't read SEX yet, but at first glance it looks like you would just place the encrypted <content/> element inside the <box/> element.
  237. vanitasvitae both in 1:1 and 1:n
  238. dwd Zash, Technically, namespaces are indeed meant to be a URI, but you have to accept any old junk.
  239. igoose has joined
  240. pdurbin has joined
  241. Lance has joined
  242. alacer has joined
  243. alacer has left
  244. alacer has joined
  245. pdurbin has left
  246. Lance has left
  247. sezuan has left
  248. Lance has joined
  249. waqas has left
  250. rtq3 has left
  251. COM8 has joined
  252. COM8 has left
  253. j.r has joined
  254. alacer has left
  255. Steve Kille has left
  256. Steve Kille has joined
  257. frainz has left
  258. alacer has joined
  259. frainz has joined
  260. goffi has left
  261. oli has left
  262. oli has joined
  263. goffi has joined
  264. marc_ has left
  265. marc_ has joined
  266. wojtek has joined
  267. typikol has joined
  268. wojtek has left
  269. typikol has left
  270. rtq3 has joined
  271. Nekit has left
  272. Nekit has joined
  273. Ge0rG jonas’: did I dream it up or was there also talk of moving https://xmpp.org/extensions/xep-0300.html#table-1 into 414?
  274. igoose has left
  275. marc_ has left
  276. andy has left
  277. sezuan has joined
  278. sezuan has left
  279. sezuan has joined
  280. alacer has left
  281. pdurbin has joined
  282. sezuan has left
  283. sezuan has joined
  284. sezuan has left
  285. sezuan has joined
  286. igoose has joined
  287. Nekit has left
  288. Nekit has joined
  289. alameyo has left
  290. alameyo has joined
  291. pdurbin has left
  292. rtq3 has left
  293. marc_ has joined
  294. david has joined
  295. andy has joined
  296. rtq3 has joined
  297. debacle has left
  298. Andrew Nenakhov has joined
  299. rion has left
  300. rion has joined
  301. david has left
  302. david has joined
  303. frainz has left
  304. frainz has joined
  305. sezuan has left
  306. debacle has joined
  307. Lance has left
  308. Yagiza has left
  309. jonas’ Ge0rG, I don’t think that belongs in '414 because it describes wire protocol, not policy
  310. debacle has left
  311. rtq3 has left
  312. lnj has left
  313. rtq3 has joined
  314. lnj has joined
  315. Lance has joined
  316. Ge0rG jonas’: that's a typical task for a registry, not for a normal XEP
  317. jonas’ indeed
  318. jonas’ it doesn’t belong in '414 anyways
  319. Ge0rG IMHO it's better in 414 than in 300, because it can be extended more easily
  320. igoose has left
  321. igoose has joined
  322. lovetox has joined
  323. Ge0rG I forgot suggesting to rename SCE into Stanza Encryption (for) XML.
  324. pep. it is never too late!
  325. dwd Ge0rG, I'm old enough to remember SXE, so I'd rather not.
  326. Ge0rG dwd: Shared XML Editing?
  327. Zash All these TLAs
  328. dwd Ge0rG, Indeed. A mechanism for realtime editing of XML which exchanged chunks of XML describing the edits on an XML document only marginally less efficiently than exchanging the entire document each time.
  329. Ge0rG That sounds frighteningly close to SCE
  330. Zash Sounds like Google Wave, but simpler.
  331. dwd Zash, I vaguely recall a conversaiton with the authors wherein they suggested they were "Post Operational Transform", which had me scratching my head in bewilderment.
  332. dwd But then, I always confused Operational Transform with Operating Thetan.
  333. dwd vanitasvitae, But actually "Stanza Encrypted Content" would make for an amusing acronym.
  334. pdurbin has joined
  335. Zash Oh no
  336. lumi has left
  337. lumi has joined
  338. goffi has left
  339. dwd More amusingly, Flow already misread it as that.
  340. pdurbin has left
  341. Kacper has left
  342. Kacper has joined
  343. Nekit has left
  344. rtq3 has left
  345. UsL has left
  346. UsL has joined
  347. mimi89999 has left
  348. lovetox has left
  349. eevvoor has joined
  350. UsL has left
  351. lnj has left
  352. andy has left
  353. rtq3 has joined
  354. waqas has joined
  355. karoshi has left
  356. rtq3 has left
  357. Lance has left
  358. eevvoor has left