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


  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


  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’


  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