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
rtq3has left
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?
andyhas left
Nekithas left
Nekithas joined
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
j.rhas left
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.
Lancehas left
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.
andyhas joined
pep.
vanitasvitae, this https://geekplace.eu/xeps/xep-sce/xep-sce.html ?
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?
COM8has joined
COM8has left
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>
Nekithas left
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..
Nekithas joined
rtq3has joined
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.
igoosehas joined
pdurbinhas joined
Lancehas joined
alacerhas joined
alacerhas left
alacerhas joined
pdurbinhas left
Lancehas left
sezuanhas left
Lancehas joined
waqashas left
rtq3has left
COM8has joined
COM8has left
j.rhas joined
alacerhas left
Steve Killehas left
Steve Killehas joined
frainzhas left
alacerhas joined
frainzhas joined
goffihas left
olihas left
olihas joined
goffihas joined
marc_has left
marc_has joined
wojtekhas joined
typikolhas joined
wojtekhas left
typikolhas left
rtq3has joined
Nekithas left
Nekithas joined
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?
igoosehas left
marc_has left
andyhas left
sezuanhas joined
sezuanhas left
sezuanhas joined
alacerhas left
pdurbinhas joined
sezuanhas left
sezuanhas joined
sezuanhas left
sezuanhas joined
igoosehas joined
Nekithas left
Nekithas joined
alameyohas left
alameyohas joined
pdurbinhas left
rtq3has left
marc_has joined
davidhas joined
andyhas joined
rtq3has joined
debaclehas left
Andrew Nenakhovhas joined
rionhas left
rionhas joined
davidhas left
davidhas joined
frainzhas left
frainzhas joined
sezuanhas left
debaclehas joined
Lancehas left
Yagizahas left
jonas’
Ge0rG, I don’t think that belongs in '414 because it describes wire protocol, not policy
debaclehas left
rtq3has left
lnjhas left
rtq3has joined
lnjhas joined
Lancehas joined
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
igoosehas left
igoosehas joined
lovetoxhas joined
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.