I think the guarantee of uniqueness for (xep359-id, xep359-id-by) is not
helpful if the xep359-id-by entity cannot be trusted to be xep359
compliant (= non malicious).
This is for example the case in public MUCs. In fact in MUCs, there is
only one xep359-id-by that can/must be trusted, which is the MUC itself.
Thus for MUCs, the xep359-id-by being the MUC is basically something we
could imply, because in general, other xep359-id-by can not be trusted.
In direct messages it's not that clear, however it is also obvious that
the xep359-id-by must be either the sender or the recipient's origin-id
(the MAM stanza id are different on each server and cannot be seen by
the other user, so can't be used for anything). If any of the two does
not follow the recommendation to generate globally unique IDs, not
providing the by attribute may cause issues. However for this to cause
issues, it needs one of the two to act malicious, because even if you
don't guarantee unique ids, collisions are very unlikely if not caused
intentionally. If they act malicious, then even providing a by attribute
won't solve anything, as malicious actors can just decide to not follow
the uniqueness requirement of (xep359-id, xep359-id-by) as well.
For the very same reason, you don't need a by when requesting messages
by id from MAM, because the id must always be the one assigned by the
archive server.
The only reason why I could imaging the by attribute to be useful would
be server-side rewriting (which for example won't work for e2e-encrypted
messages and also requires indefinite server history): When by is set
and the id is in the archive, the server could replace the by/id with a
better suited one (that is known to the intended recipient). This way it
would possible that clients would be fine with only ever knowing one id
of a message (the local servers archive id) and all other ids can be
ignored (or even redacted by the server). However I don't think this is
something we'd like servers to do (for various reasons and because of
the problems mentioned).
so tl;dr: Usually the by is not required when referencing a message as
it's value is implicit for the usecase.
On 12/18/19 11:59 AM, Florian Schmaus wrote:
Oh, the IDs are unique. But only if you concatenate the 'by' value with
the ID. Or, in other words, the tuple (xep359-id, xep359-id-by) is
guaranteed by xep359 to be globally unique.
One reason why xep359 makes this distinction is to prevent ID spoofing.
Consider an archive which contains a message with the xep359-id 'id1'
and another user now refers to this message just using 'id1'. If now an
(malicious) entity would be able to add to the archive another message
with the same xep359-id 'id1', but a different xep359-id-by value, then
it is not clear anymore which message is refereed to.
Hence one should always use the tuple (xep359-id, xep359-id-by) when
referring to stanzas using xep359 IDs. And this is the coordinate system
fastening should use to establish a link to other messages.
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
