Well, good morning, the lack of stable stanza IDs was the biggest problem in XMPP ever. For ourselves, we fixed it the following way:
1. Each server generates unique stanza IDs according to XEP-0359. 2. Attached Stanza IDs are relayed as they were, and local server assigns own IDs for incoming and outgoing stanzas. 3. When interacting with the message, clients and server interact using own IDs. 4. For outgoing messages, the client assigns a provisional unique ID for the message and sends it away. The server assigns a unique server ID to the message and relays the message to its destination, and sends a receipt with the server ID to the client. Client considered the message as unsent until it receives that receipt, and retries sending it until it obtains said receipts. 5. XEP-0333 was extended and we put all stanza IDs into <displayed />, so both local and remote server can use their respective IDs. We call XEP that describes point 4 from above as XEP-DELIVERY (when you get numbers in high hundreds it gets really silly), its draft text can be found here <https://docs.google.com/document/d/1UmHx_ryCW1lffMiwv1ONSjvZL2cO5pd9OOPxT-banK0/edit?usp=sharing> . On Thu, 17 Oct 2024 at 14:33, Dave Cridland <[email protected]> wrote: > 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. > > _______________________________________________ > Standards mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
