-
dwd
vanitasvitae, Love your SCE examples.
-
vanitasvitae
dwd: :D
-
vanitasvitae
Glad to hear that :P
-
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?
-
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.
-
pep.
yep, that's also how I picture it
-
vanitasvitae
dwd: thats right
-
vanitasvitae
Encryption mechanisms would define profiles that use sce
-
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.
-
dwd
I'm not sure if that's OK or not, to be honest.
-
vanitasvitae
Yep thats right
-
pep.
dwd, what do you mean it's not ok
-
dwd
pep., An element whose definition depends on the parent (containing) element seems like stretching the use of XML quite a bit.
-
pep.
I'm not sure I understand this entirely
-
dwd
Still, the <content/> concept, and some standardized rules on what goes in it, what stays out, and so on all seems sensible.
-
pep.
Isn't that what all XEPs are about?
-
vanitasvitae
I'm also not entirely sure what you mean by stretching the use of XML 😀
-
dwd
pep., Not really. A <delay/> element has fixed semantics, and doesn't require the containing element to say what its content means.
-
vanitasvitae
ah
-
pep.
What if we add a @node or @whatever with the ns of the encryption mechanism?
-
pep.
So it doesn't need to be contained in a subelement
-
pep.
(of message)
-
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.
-
vanitasvitae
so you are not sure about "an openpgp element INSIDE an envelope must be treated differently from a "normal" openpgp element"?
-
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.
-
vanitasvitae
ah got it.
-
vanitasvitae
hmm.
-
pep.
dwd, we can still have common elements
-
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.
-
pep.
And these more specific XEPs define how these elements are used
-
dwd
pep., What does the element tell us?
-
pep.
pad, date, etc.
-
dwd
pep., Those are in <content/> as <rpad/>, <time/>, and so on.
-
pep.
Ok let me read the thing again
-
dwd
pep., I'm totally on board with <content/>. It's <envelope/> I'm a little worried by.
-
vanitasvitae
dwd, I definitely see what you mean. We could even save some chars by removing the encapsulating <envelope/> element.
-
vanitasvitae
I think the main reason for me was to "bundle" the sce stuff together if that makes sense.
-
vanitasvitae
Also thats the way OX does it 😀
-
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.
-
pep.
vanitasvitae, this https://geekplace.eu/xeps/xep-sce/xep-sce.html ?
-
pep.
(that's the last version?)
-
dwd
pep., https://xmpp.org/extensions/inbox/xep-sce.html
-
pep.
oh it's in the inbox now
-
vanitasvitae
pep., it made its way into the inbox 😀
-
dwd
pep., Hence I'm reading it. :-)
-
vanitasvitae
😀
-
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/>.
-
vanitasvitae
sounds sensible for now
-
pep.
vanitasvitae, I don't think you should be using eu.siacs.conversations.axolotl as a example ns btw
-
pep.
Though technically there's nothing that prevents it..
-
vanitasvitae
so for OMEMO we would have <encrypted> <header>...</header> <content> <rpad etc./> <payload>...</payload> </content> </encrypted>
-
Zash
Doesn't the namespace have to be an URI?
-
pep.
Zash, I meant, if that's the current OMEMO ns, nothing actually prevents reusing it and shoving more stuff in it
-
pep.
vanitasvitae, right, and then in this case <payload> is conflicting and we need to change the NS :p
-
vanitasvitae
ah no wait, I messed up my example. <encrypted> <header>...</header> <payload> (here be encrypted <content/>) </payload> </encrypted>
-
pep.
dwd, I get your point now. I also don't think it hurts
-
pep.
I also don't know all encryption mechanisms out there, maybe that won't work for one..
-
vanitasvitae
hehe, going with <envelope/> would maybe allow for a transition period *duck*
-
pep.
What about the multi-recipient case, can just one <envelope/> tag be used for this?
-
pep.
https://op-co.de/tmp/SEX.html something à la <multibox/> here
-
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.
-
vanitasvitae
both in 1:1 and 1:n
-
dwd
Zash, Technically, namespaces are indeed meant to be a URI, but you have to accept any old junk.
-
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?
-
jonas’
Ge0rG, I don’t think that belongs in '414 because it describes wire protocol, not policy
-
Ge0rG
jonas’: that's a typical task for a registry, not for a normal XEP
-
jonas’
indeed
-
jonas’
it doesn’t belong in '414 anyways
-
Ge0rG
IMHO it's better in 414 than in 300, because it can be extended more easily
-
Ge0rG
I forgot suggesting to rename SCE into Stanza Encryption (for) XML.
-
pep.
it is never too late!
-
dwd
Ge0rG, I'm old enough to remember SXE, so I'd rather not.
-
Ge0rG
dwd: Shared XML Editing?
-
Zash
All these TLAs
-
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.
-
Ge0rG
That sounds frighteningly close to SCE
-
Zash
Sounds like Google Wave, but simpler.
-
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.
-
dwd
But then, I always confused Operational Transform with Operating Thetan.
-
dwd
vanitasvitae, But actually "Stanza Encrypted Content" would make for an amusing acronym.
-
Zash
Oh no
-
dwd
More amusingly, Flow already misread it as that.