The URIs will already be super long so I don't think saving a few bytes to omit the sid is that important as far as overhead. Our db model for devices is currently keyed to JID + deviceId, because we normally don't know identityKey until the bundle is fetched. We could also prepend the 32-bit sid to the binary payload data, and use base32 instead of hex to save a character.
I think it's useful to have the sid because otherwise we'll have entries floating around in our db without a sid, and then also entries floating around without an identityKey from PEP, and we'll have to merge them during the bundle fetching process which would be kinda weird and a lot harder than just including the sid in the URI. On Thu, Oct 27, 2016 at 12:17 PM, Daniel Gultsch <dan...@gultsch.de> wrote: > Hi Chris, > > is there a reason you are including the SID in the URL? > > If not I would just propose doing > > xmpp:fe...@allfools.lit?omemo=070c42a11644a78b2f6f56213be468 > 6374222895eb67b781abc44b860c47656c,e3898c2083b830a5fcb5e49632a344 > 2837f8e8a24bea2f39e37d632807c82871 > > instead. > > Or maybe ?omemo=key&omemo=key2 but ?omemo=key,key2 safes some bytes > > cheers > Daniel > > 2016-10-27 20:51 GMT+02:00 Chris Ballinger <ch...@chatsecure.org>: > > Hey, I'd like to propose an OMEMO addition to XMPP URIs so you can > pre-share > > the identityKey for each of your devices through another channel. > Currently > > OTR fingerprints in URIs are formatted like this: > > http://xmpp.org/extensions/xep-0364.html#sect-idp672480 > > > > xmpp:fe...@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D245 > 24B4C54338 > > > > Since each Device ID would need a separate entry, we'd need to do a > prefix > > mechanism: > > > > xmpp:fe...@allfools.lit?omemo-sid-24145=070c42a11644a78b2f6f56213be468 > 6374222895eb67b781abc44b860c47656c;omemo-sid-55126= > e3898c2083b830a5fcb5e49632a3442837f8e8a24bea2f39e37d632807c82871 > > > > We could also use Base32 (or URL safe Base64?) to shorten the links > > slightly. Super long links are allowed on iOS, not sure about Android or > > other platforms. > > > > On Fri, Oct 7, 2016 at 11:19 AM, Fabian Beutel <fabian.beu...@gmx.de> > wrote: > >> > >> Maybe this is a good time to bring up a question regarding full stanza > >> encryption [1]: > >> > >> Maybe we can include a mechanism for encrypting full stanzas (including > >> IQs), not just Message's <body> elements? Or do you think a separate XEP > >> building upon the defenitions of the current one would be better suited > >> for that? > >> > >> I'm especially thinking about jingle negotiations that can leak a lot of > >> meta data. Even in the case of "OMEMO Encrypted Jingle File Transfer" > >> full stanza encryption prevents a lot of information leakage. > >> > >> Best regards, > >> Fabian > >> > >> [1] I tried to bring up a similar discussion on OpenPGP recently, see > >> https://mail.jabber.org/pipermail/standards/2016-September/031440.html > >> > >> On 01.10.2016 13:49, Daniel Gultsch wrote: > >> > FYI: There is a pending PR [1] that rewrites the OMEMO XEP to use the > >> > (well documented) Olm specification and also adds some minor > >> > improvements that came up during the audit [2]. > >> > > >> > cheers > >> > Daniel > >> > > >> > [1]: https://github.com/xsf/xeps/pull/251 > >> > [2]: https://conversations.im/omemo/audit.pdf > >> > > >> > 2015-10-28 16:42 GMT+01:00 XMPP Extensions Editor <edi...@xmpp.org>: > >> >> The XMPP Extensions Editor has received a proposal for a new XEP. > >> >> > >> >> Title: OMEMO Encryption > >> >> > >> >> Abstract: This specification defines a protocol for end-to-end > >> >> encryption in one-on-one chats that may have multiple clients per > account. > >> >> > >> >> URL: http://xmpp.org/extensions/inbox/omemo.html > >> >> > >> >> The XMPP Council will decide in the next two weeks whether to accept > >> >> this proposal as an official XEP. > >> >> > >> > _______________________________________________ > >> > Standards mailing list > >> > Info: https://mail.jabber.org/mailman/listinfo/standards > >> > Unsubscribe: standards-unsubscr...@xmpp.org > >> > _______________________________________________ > >> > > >> > >> _______________________________________________ > >> Standards mailing list > >> Info: https://mail.jabber.org/mailman/listinfo/standards > >> Unsubscribe: standards-unsubscr...@xmpp.org > >> _______________________________________________ > > > > > > > > _______________________________________________ > > Standards mailing list > > Info: https://mail.jabber.org/mailman/listinfo/standards > > Unsubscribe: standards-unsubscr...@xmpp.org > > _______________________________________________ > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: standards-unsubscr...@xmpp.org > _______________________________________________ >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
