dwdvanitasvitae, 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?
dwdFor 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
vanitasvitaedwd: thats right
vanitasvitaeEncryption mechanisms would define profiles that use sce
dwdThat 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.
dwdI'm not sure if that's OK or not, to be honest.
vanitasvitaeYep thats right
pep.dwd, what do you mean it's not ok
dwdpep., 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
dwdStill, 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?
vanitasvitaeI'm also not entirely sure what you mean by stretching the use of XML 😀
dwdpep., Not really. A <delay/> element has fixed semantics, and doesn't require the containing element to say what its content means.
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
dwdpep., 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.
vanitasvitaeso you are not sure about "an openpgp element INSIDE an envelope must be treated differently from a "normal" openpgp element"?
dwdvanitasvitae, I'm not actually sure you need the <envelope/> element at all, given that OMEMO, OpenPGP, etc all have to define its use anyway.
vanitasvitaeah got it.
pep.dwd, we can still have common elements
dwdvanitasvitae, 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
dwdpep., What does the element tell us?
pep.pad, date, etc.
dwdpep., Those are in <content/> as <rpad/>, <time/>, and so on.
pep.Ok let me read the thing again
dwdpep., I'm totally on board with <content/>. It's <envelope/> I'm a little worried by.
vanitasvitaedwd, I definitely see what you mean. We could even save some chars by removing the encapsulating <envelope/> element.
vanitasvitaeI think the main reason for me was to "bundle" the sce stuff together if that makes sense.
vanitasvitaeAlso thats the way OX does it 😀
dwdvanitasvitae, 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 ?
vanitasvitaepep., it made its way into the inbox 😀
dwdpep., Hence I'm reading it. :-)
vanitasvitaeso basically we could get rid of <envelope/> and let the encryption mechanisms replace their <payload/> or whatever payload element they use by <sce:content/>.
vanitasvitaesounds 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..
vanitasvitaeso for OMEMO we would have
ZashDoesn'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
vanitasvitaeah no wait, I messed up my example.
<payload> (here be encrypted <content/>) </payload>
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..
vanitasvitaehehe, 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
vanitasvitaeI haven't read SEX yet, but at first glance it looks like you would just place the encrypted <content/> element inside the <box/> element.
vanitasvitaeboth in 1:1 and 1:n
dwdZash, Technically, namespaces are indeed meant to be a URI, but you have to accept any old junk.
Steve Killehas left
Steve Killehas joined
Ge0rGjonas’: did I dream it up or was there also talk of moving https://xmpp.org/extensions/xep-0300.html#table-1 into 414?
Andrew Nenakhovhas joined
jonas’Ge0rG, I don’t think that belongs in '414 because it describes wire protocol, not policy
Ge0rGjonas’: that's a typical task for a registry, not for a normal XEP
jonas’it doesn’t belong in '414 anyways
Ge0rGIMHO it's better in 414 than in 300, because it can be extended more easily
Ge0rGI forgot suggesting to rename SCE into Stanza Encryption (for) XML.
pep.it is never too late!
dwdGe0rG, I'm old enough to remember SXE, so I'd rather not.
Ge0rGdwd: Shared XML Editing?
ZashAll these TLAs
dwdGe0rG, 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.
Ge0rGThat sounds frighteningly close to SCE
ZashSounds like Google Wave, but simpler.
dwdZash, I vaguely recall a conversaiton with the authors wherein they suggested they were "Post Operational Transform", which had me scratching my head in bewilderment.
dwdBut then, I always confused Operational Transform with Operating Thetan.
dwdvanitasvitae, But actually "Stanza Encrypted Content" would make for an amusing acronym.
dwdMore amusingly, Flow already misread it as that.