On Wed, 2023-02-22 at 19:02 +0100, Florian Schmaus wrote:
> That is where we already think different. The more archives messages
> are
> contained in, the higher the chances are that they are preserved and
> recoverable. Which is usually a good thing.
The ground truth for messages received by the user is the receiving
user's server archive - a message that is not stored there should cause
an error to be stored in the sender's archive and thus should not be
considered part of the conversation between the two.
The ground truth for messages in a groupchat is the view of the
groupchat server (MUC/MIX/...).
Any other archive might be incomplete (without knowing about that) and
thus is not suitable as a reference when trying to recover a full view
of a conversation history. If you want groupchat messages to be
preserved by your local server, it could do so by identifying the
message using the stanza-id of the groupchat server qualified with the
groupchat JID ("by-attribute").
> So groupchat message are ideally in the sending users MAM archive, in
> the archive of the groupchat (MUC/MIX) and in the receiving users
> archive. Therefore, they could have three <stanza-id/> elements when
> arriving at their destination.
You can have as many as you want. Still as a client developer I'm
happily going to ignore them. I doubt any client developer wants to
create the complexity of building and synchronizing a message history
from multiple archives, so one has to decide for one and it only makes
sense to use the ground truth.
> Even in your design, you need to know how to select the stanza-id you
> will store in your local store based on the 'by' attribute's value.
Technically, I wouldn't need the by-attribute if I had certainty that
my server wouldn't want to add its own archive id (which they typically
don't, but could). However, when saying I don't need the by-attribute,
I was referring to a by-attribute when referencing the message. Because
the original value of the by-attribute of the stanza-id of a message is
not even preserved in my local state (as I pointed out).
> That is where, I believe, we are on the same page. It's not rocket
> science. The hard part, which is maybe already solved, is, if the
> MUC(/MIX) stanza-id by attribute is [email protected] or
> muc.example.org. But that is probably for MAM to specify?
That's actually well-defined in XEP-0313 since 2017 [1] and as far as I
know, all client and server implementations (that support MAM using the
mam:2 namespace) get this done properly.
>
> I think the only thing we really are not on the same page is if a
> reference should be fully qualified, i.e., the tuple of (id, by), or
> not. And I would prefer explicit over implicit here.
As a client developer, even if you would require me to explicitly put
the by-attribute with every message reference, I would:
- When sending a message reference: recover the by-attribute from the
implicit value that I know it must've had to be stored as such id
(sender id or archive id).
- When receiving a message reference: Ignore any "wrong" by-attribute
in message references and just take the value that I implicitly know
must've been used when referencing (following Postel's law).
This would turn the by-attribute in a message reference into entirely
useless boilerplate that is generated out of thin air by the sender and
ignored by the recipient.
Marvin
[1] https://xmpp.org/extensions/xep-0313.html#archives_id
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: [email protected]
_______________________________________________
