All bytes count are not to be taken as their actual values because these messages lack a lot of information normally present, however the general idea that each of the levels safes more should be correct. Also relevant is obviously the reduction of stanzas and xml elements.
<message id='my-message'>
<body>Original</body>
<origin-id id='my-message' />
</message><message id='replace-1'>
<apply-to id='my-message' type='urn:example:edit:0' only='latest'>
<e name='body' />
<e name='replace' ns='urn:xmpp:message-correct:0' />
</apply-to>
<body>Replacement 1</body>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<origin-id id='replace-1' />
<other-meta />
</message><message id='replace-2'>
<apply-to id='my-message' type='urn:example:edit:0' only='latest'>
<e name='body' />
<e name='encrypted' ns='eu.siacs.conversations.axolotl' />
<e name='replace' ns='urn:xmpp:message-correct:0' />
</apply-to>
<body>[This message is OMEMO encrypted]</body>
<encrypted xmlns='eu.siacs.conversations.axolotl'>[Something that makes body = Replacement 2</encrypted>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<origin-id id='replace-2' />
<more-meta />
</message>Total bytes: 790 (excluding encryption)
<message id='replace-3'>
<apply-to id='my-message' type='urn:example:edit:0' only='latest'>
<e name='body' />
</apply-to>
<body>Replacement 1</body>
<origin-id id='replace-1' />
<other-meta />
</message>Server will just send these three messages as is, but remove the contents of <apply-to> and only attribute, as these are only meta data for the server. However server adds stanza id to every message:
<message id='my-message'>
<body>Original</body>
<origin-id id='my-message' />
<stanza-id id='archive1' />
<delay />
</message><message id='replace-1'>
<apply-to id='my-message' type='urn:example:edit:0' />
<body>Replacement 1</body>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<origin-id id='replace-1' />
<other-meta />
<stanza-id id='archive2' />
<delay />
</message><message id='replace-2'>
<apply-to id='my-message' type='urn:example:edit:0' />
<body>[This message is OMEMO encrypted]</body>
<encrypted xmlns='eu.siacs.conversations.axolotl'>[Something that makes body = Replacement 2</encrypted>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<origin-id id='replace-2' />
<more-meta />
<stanza-id id='archive3' />
<delay />
</message>Total bytes: 680 (excluding encryption)
<message id='replace-3'>
<apply-to id='my-message' type='urn:example:edit:0' />
<body>Replacement 1</body>
<origin-id id='replace-1' />
<other-meta />
</message>Server will send a single message to the client, including compact information on existence of other messages. The <applied> elements are to be ordered by date.
<message id='my-message'>
<body>Original</body>
<origin-id id='my-message' />
<stanza-id id='archive1' />
<delay />
</message>
<applied from='X' id='archive2' type='urn:example:edit:0' only='latest' />
<applied from='X' id='archive3' type='urn:example:edit:0' only='latest' />If clients know urn:example:edit:0 type, they already know that only the latest version is relevant, clients that use the legacy standard don't know but can see from only='latest', that only the newest of this type and sender is relevant. Both thus only fetch the full archive3 message. Again contents of <apply-to> and only attribute are removed when fetching the full message from archive.
<message id='replace-2'>
<apply-to id='my-message' type='urn:example:edit:0' />
<body>[This message is OMEMO encrypted]</body>
<encrypted xmlns='eu.siacs.conversations.axolotl'>[Something that makes body = Replacement 2</encrypted>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<origin-id id='replace-2' />
<more-meta />
<stanza-id id='archive3' />
<delay />
</message>Total bytes: 560 (excluding encryption)
Server sends a single message, expanding the fastened messages (as seen in Compact), but only using the referenced elements:
<message id='my-message'>
<body>Original</body>
<origin-id id='my-message' />
<stanza-id id='archive1' />
<delay />
</message>
<applied from='X' id='archive2' type='urn:example:edit:0' only='latest' />
<applied from='X' id='archive3' type='urn:example:edit:0' only='latest'>
<body>[This message is OMEMO encrypted]</body>
<encrypted xmlns='eu.siacs.conversations.axolotl'>[Something that makes body = Replacement 2</encrypted>
<replace id='my-message' xmlns='urn:xmpp:message-correct:0'/>
<delay />
</applied>Again it doesn't matter if the receiving client understands urn:example:edit:0 or only the legacy standard. Un both cases the client can directly process the edit without
Total bytes: 410 (excluding encryption)
The smart mode will understand the urn:example:edit:0 type and directly apply it - with some meta data being attached so that clients can display that the message was edited. Thus even if the client doesn't understand urn:example:edit:0 they will see only the updated message.
<message id='my-message'>
<body>[This message is OMEMO encrypted]</body>
<encrypted xmlns='eu.siacs.conversations.axolotl'>[Something that makes body = Replacement 2</encrypted>
<stanza-id id='archive1' />
<delay />
<edited id='archive3' xmlns='urn:example:edit:0'><delay /></edited>
</message>
<applied from='X' id='archive2' type='urn:example:edit:0' only='latest' />
<applied from='X' id='archive3' type='urn:example:edit:0' only='latest' />Total bytes: 310 (excluding encryption)
I think it should be noted that the dumb mode must contine to exist beside the others (so requesters have to specify which mode they want). The dumb mode is used to request the full message for Compact MAM but most importantly can also be used to fetch intermediary details. I don't think we should make a part of the history unreachable using this protocol as this will inevitably result in people setting up what is known as a bouncer in the IRC world, just so they can see all steps of a message edit to ensure people were not changing the meaning (but maybe fixed some typo) after people replied.