XSF Discussion - 2019-06-24

  1. dwd

    vanitasvitae, Love your SCE examples.

  2. vanitasvitae

    dwd: :D

  3. vanitasvitae

    Glad to hear that :P

  4. 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?

  5. 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.

  6. pep.

    yep, that's also how I picture it

  7. vanitasvitae

    dwd: thats right

  8. vanitasvitae

    Encryption mechanisms would define profiles that use sce

  9. 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.

  10. dwd

    I'm not sure if that's OK or not, to be honest.

  11. vanitasvitae

    Yep thats right

  12. pep.

    dwd, what do you mean it's not ok

  13. dwd

    pep., An element whose definition depends on the parent (containing) element seems like stretching the use of XML quite a bit.

  14. pep.

    I'm not sure I understand this entirely

  15. dwd

    Still, the <content/> concept, and some standardized rules on what goes in it, what stays out, and so on all seems sensible.

  16. pep.

    Isn't that what all XEPs are about?

  17. vanitasvitae

    I'm also not entirely sure what you mean by stretching the use of XML 😀

  18. dwd

    pep., Not really. A <delay/> element has fixed semantics, and doesn't require the containing element to say what its content means.

  19. vanitasvitae


  20. pep.

    What if we add a @node or @whatever with the ns of the encryption mechanism?

  21. pep.

    So it doesn't need to be contained in a subelement

  22. pep.

    (of message)

  23. 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.

  24. vanitasvitae

    so you are not sure about "an openpgp element INSIDE an envelope must be treated differently from a "normal" openpgp element"?

  25. 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.

  26. vanitasvitae

    ah got it.

  27. vanitasvitae


  28. pep.

    dwd, we can still have common elements

  29. 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.

  30. pep.

    And these more specific XEPs define how these elements are used

  31. dwd

    pep., What does the element tell us?

  32. pep.

    pad, date, etc.

  33. dwd

    pep., Those are in <content/> as <rpad/>, <time/>, and so on.

  34. pep.

    Ok let me read the thing again

  35. dwd

    pep., I'm totally on board with <content/>. It's <envelope/> I'm a little worried by.

  36. vanitasvitae

    dwd, I definitely see what you mean. We could even save some chars by removing the encapsulating <envelope/> element.

  37. vanitasvitae

    I think the main reason for me was to "bundle" the sce stuff together if that makes sense.

  38. vanitasvitae

    Also thats the way OX does it 😀

  39. 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.

  40. pep.

    vanitasvitae, this https://geekplace.eu/xeps/xep-sce/xep-sce.html ?

  41. pep.

    (that's the last version?)

  42. dwd

    pep., https://xmpp.org/extensions/inbox/xep-sce.html

  43. pep.

    oh it's in the inbox now

  44. vanitasvitae

    pep., it made its way into the inbox 😀

  45. dwd

    pep., Hence I'm reading it. :-)

  46. vanitasvitae


  47. 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/>.

  48. vanitasvitae

    sounds sensible for now

  49. pep.

    vanitasvitae, I don't think you should be using eu.siacs.conversations.axolotl as a example ns btw

  50. pep.

    Though technically there's nothing that prevents it..

  51. vanitasvitae

    so for OMEMO we would have <encrypted> <header>...</header> <content> <rpad etc./> <payload>...</payload> </content> </encrypted>

  52. Zash

    Doesn't the namespace have to be an URI?

  53. pep.

    Zash, I meant, if that's the current OMEMO ns, nothing actually prevents reusing it and shoving more stuff in it

  54. pep.

    vanitasvitae, right, and then in this case <payload> is conflicting and we need to change the NS :p

  55. vanitasvitae

    ah no wait, I messed up my example. <encrypted> <header>...</header> <payload> (here be encrypted <content/>) </payload> </encrypted>

  56. pep.

    dwd, I get your point now. I also don't think it hurts

  57. pep.

    I also don't know all encryption mechanisms out there, maybe that won't work for one..

  58. vanitasvitae

    hehe, going with <envelope/> would maybe allow for a transition period *duck*

  59. pep.

    What about the multi-recipient case, can just one <envelope/> tag be used for this?

  60. pep.

    https://op-co.de/tmp/SEX.html something à la <multibox/> here

  61. 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.

  62. vanitasvitae

    both in 1:1 and 1:n

  63. dwd

    Zash, Technically, namespaces are indeed meant to be a URI, but you have to accept any old junk.

  64. 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?

  65. jonas’

    Ge0rG, I don’t think that belongs in '414 because it describes wire protocol, not policy

  66. Ge0rG

    jonas’: that's a typical task for a registry, not for a normal XEP

  67. jonas’


  68. jonas’

    it doesn’t belong in '414 anyways

  69. Ge0rG

    IMHO it's better in 414 than in 300, because it can be extended more easily

  70. Ge0rG

    I forgot suggesting to rename SCE into Stanza Encryption (for) XML.

  71. pep.

    it is never too late!

  72. dwd

    Ge0rG, I'm old enough to remember SXE, so I'd rather not.

  73. Ge0rG

    dwd: Shared XML Editing?

  74. Zash

    All these TLAs

  75. 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.

  76. Ge0rG

    That sounds frighteningly close to SCE

  77. Zash

    Sounds like Google Wave, but simpler.

  78. 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.

  79. dwd

    But then, I always confused Operational Transform with Operating Thetan.

  80. dwd

    vanitasvitae, But actually "Stanza Encrypted Content" would make for an amusing acronym.

  81. Zash

    Oh no

  82. dwd

    More amusingly, Flow already misread it as that.