[Standards] XEP-0308: Last Message Correction and Carbons
dave at cridland.net
Fri Sep 30 16:25:23 UTC 2016
On 30 September 2016 at 17:12, Kevin Smith <kevin.smith at isode.com> wrote:
> On 30 Sep 2016, at 10:01, Dave Cridland <dave at cridland.net> wrote:
>> On 30 September 2016 at 09:49, Kevin Smith <kevin.smith at isode.com> wrote:
>>>> On 29 Sep 2016, at 22:58, Dave Cridland <dave at cridland.net> wrote:
>>>> On 29 Sep 2016 22:00, "Kevin Smith" <kevin.smith at isode.com> wrote:
>>>>> On 29 Sep 2016, at 21:17, Dave Cridland <dave at cridland.net> wrote:
>>>>>> (And please, folks, unless you can think of something I can't, a
>>>>>> randomish string prefix and a counter is fine).
>>>>> The dangers of using counters in stanza IDs and leaking information :)
>>>> Yes, quite. I meant to argue against generating UUIDs and otherwise using a lot of entropy, and got carried away - but a random key and hmaccing a counter should be okay.
>>>> Point being, if the stanza id attribute is causing us a problem, that can be fixed in compatible ways.
>>> Possibly true, yes. It doesn’t resolve the MUC issue, but maybe it does everything else. We should probably explicitly call out in carbons and MAM the importance of preserving the id in the header.
>> The MUC reflection-detection issue? I *think* that's the only use-case
>> after however many years.
>> We could mark just the reflected stanza, couldn't we?
> You mean add an element into the outgoing MUC message saying original-id-was X? Seems that would work.
I was thinking simply <this-is-your-reflection-message
xmlns='urn:xmpp:reflection'/> actually. Could include the original
stanza id, but I can't think of a use-case.
I suppose '308 might prefer if the original id were there in the
broadcast message in case you want to correct a message before you've
even seen the reflected copy, though.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
More information about the Standards