On 24.02.23 16:47, Tedd Sterr wrote:
What I'm less sure of is the benefit 'by' actually brings in practice. If there are multiple stanza-ids then it obviously serves to differentiate them, but why the need for multiple? The client's id is the origin-id (so it can cross-reference with its archive) and the MUC's id is the stanza-id (so it can be referenced for reactions, etc.) Carbons shouldn't need yet another id.
As I wrote before, if, for example, the recipient's server also stores groupchat messages in the user's archive, then the recipient will receive a groupchat message containing (at least) two stanza-id elements:
- one added by the groupchat, with the ID under which the stanza was stored in the groupchat's archive - one added by the recipient's server, with the ID under which the stanza was stored in receiving user's archiveIf the sending user's server also stores all groupchat message in the sending user's archive, then there could be easily a third stanza-id element. Arguably, the ID of this stanza-id element is in most cases of not much use to the recipient, as the recipient will probably not have access to the sender's archive. Still it may provide useful, and if it is "only" for debugging purposes.
The "carbon-to-self" topic is slightly different, but related. We currently have the asymmetry that, in the presence of carbons, other sessions of a user are able to learn the ID under which an outgoing stanza was archived in the user's archive. However the client that send this message does not get this information, because there is no carbon copy to the sending session, only to other sessions.
Some developers find it useful to become aware of the archive's ID, so there has been a discussion about how this could be achieved. This discussion is, however, unrelated to our current discussion (I believe). It is only connected by stanza-id being (assumably) the element transporting the desired information.
- Flow
OpenPGP_0x8CAC2A9678548E35.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
