Hi all,
I was skimming XEP-0490, and the optimisation of injecting multiple displayed elements into a message referencing different ids in different namespaces made me spit my tea dramatically over my keyboard. Not really, of course - tea is far too precious to waste on such things, but you get the idea.
There's clearly no better alternative, because we have clients in the wild which are quite painful about message ids, and will therefore break things if we were to rely on their ids being unique.
This got me thinking: What could we do to - if not remove this wart entirely, at least file it down so it was less of a nuisance. (I'm not sure if warts do get filed down; I am not a doctor, do not try this at home)
In a perfect world, we might remove XEP-0359 entirely - not because it is, in and of itself, a bad spec, but because it is essentially patching problems elsewhere.
So, what can we do to ensure that some tuple of the stanza attributes perhaps (from,id), or possibly (from,to,id), is unique "enough", and stable "enough", for both receivers and senders to rely on without having to inject multiple ids?
Is this worth doing - it feels like it would clean up a lot of other constructs, but some cases (MAM, perhaps?) might always need to inject other identifiers. If we were to rely on clients using unique identifers, could this be subverted in some way beneficial to an attacker?
My gut feeling is that even if we find that we're stuck with XEP-0359 in all the same cases, we might produce an interesting document about the security implications of the id attribute of stanzas, which feels like a gap worth filling.
What do you all think?
Dave.