XSF Discussion - 2019-06-24

vanitasvitae, Love your SCE examples.

dwd: :D

Glad to hear that :P

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?

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.

yep, that's also how I picture it

dwd: thats right

Encryption mechanisms would define profiles that use sce

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.

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

Yep thats right

dwd, what do you mean it's not ok

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

I'm not sure I understand this entirely

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

Isn't that what all XEPs are about?

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

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

ah

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

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

(of message)

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.

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

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.

ah got it.

hmm.

dwd, we can still have common elements

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.

And these more specific XEPs define how these elements are used

pep., What does the element tell us?

pad, date, etc.

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

Ok let me read the thing again

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

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

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

Also thats the way OX does it 😀

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.

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

(that's the last version?)

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

oh it's in the inbox now

pep., it made its way into the inbox 😀

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

😀

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

sounds sensible for now

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

Though technically there's nothing that prevents it..

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

Doesn't the namespace have to be an URI?

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

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

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

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

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

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

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

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

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.

both in 1:1 and 1:n

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

jonas’: did I dream it up or was there also talk of moving https://xmpp.org/extensions/xep-0300.html#table-1 into 414?

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

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

indeed

it doesn’t belong in '414 anyways

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

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

it is never too late!

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

dwd: Shared XML Editing?

All these TLAs

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.

That sounds frighteningly close to SCE

Sounds like Google Wave, but simpler.

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.

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

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

Oh no

More amusingly, Flow already misread it as that.