Add Archiving support for XEP-0334: Message Processing Hints

[guusdk]

When processing messages in context of message archiving, hints as defined in XEP-0334: Message Processing Hints should be taken into account.

Currently, we have these options, which affect only messages that have a text body:

• Archive one-to-one chats
• Archive group chats
• Archive stanzas for group chats
• Only archive conversations of the following room names (separated by comma)

Why don't we have an option to enable/disable stanzas for one-to-one chats?

XEP-0334 adds these hints. Note that these are specifically designed to be applicable too to stanzas that have no text body.

• no-store & no-permanent-store
• store

This all should be folded into a uniform UI and implementation.

[guusdk]

Combining the existing options and the hints from XEP-0334 leads to a lot of possible scenarios:

• Do not archive any one-to-one chat messages.
• Archive all one-to-one chat messages that have message bodies.
• Archive one-to-one chat messages that have message bodies, unless the have a no-store hint.
• Archive one-to-one chat messages that have message bodies. Also store message stanzas that have no bodies, but have a hint that they should be stored.
• Archive one-to-one chat messages that have message bodies only if they have a store hint
• Only store the message body, not the entire stanza (which makes no sense for storing message without body but with a hint)
• all of the above, but for group messages
• ...

How do we make this manageable for typical end users?

[guusdk]

Maybe replace the options that we have now with these two sets? Can we do away with the configuration distinction between group chats and one-on-on chats? Can we always log the full stanza, and do away with that option too?

Archive messages

• Never
• Always (stores message stanzas that have a text body)
• Only when instructed by client (stores message stanzas that have a text body only if they have a 'store' hint)
• Unless instructed by client not to (stores message stanzas that have a text body only if there is not a 'no-store' / 'no-permanent-store' hint)

Optionally: add a checkbox that causes only the text, not the entire stanza, to be added

Archive message metadata

• Never (never store message stanzas that have no text body)
• When instructed by client (store message stanzas that have no text body, but with a 'store' hint)
• (the option 'Always' seems dangerous to me, as this could capture unwanted message stanzas like pubsub events)

[guusdk]

This is a mock-up of the above. Note that I also made indexing an explicit choice (for #354):

[Fishbowler]

We've got the "Archive stanzas for group chats" checkbox, that gets replaced with the inverse?

Optionally: add a checkbox that causes only the text, not the entire stanza, to be added

We call it "Message metadata", but how do we know that it is indeed that?

Existing settings for comparison:

[guusdk]

I'm not sure if I'm completely tracking with you.

I would suggest to always log the entire stanza, unless the optional checkbox is checked. If that is checked then we can only log true chat messages, and not metadata.

For 'true chat messages' (these are message stanzas with a text body), I think we can have these four options:

• Never
• Always (stores message stanzas that have a text body)
• Only when instructed by client (stores message stanzas that have a text body only if they have a 'store' hint)
• Unless instructed by client not to (stores message stanzas that have a text body only if there is not a 'no-store' / 'no-permanent-store' hint)

The "metadata" that I'm referring to - for which I've probably chosen a poor word - are the 'other' message stanzas: those that have no text body. For these, we have these two options:

• Never (never store message stanzas that have no text body)
• When instructed by client (store message stanzas that have no text body, but with a 'store' hint)
  (the option 'Always' seems dangerous to me, as this could capture unwanted message stanzas like pubsub events)

(Again, if we are not logging the entire stanza, then the entire 'metadata' section should be disabled, as there is no metadata available if we only log the message body).

[guusdk]

We call it "Message metadata", but how do we know that it is indeed that?

You're right, I don't think it's possible to determine that server-sided. An attempt was made in #179 which depends on a hard-coded list of known extensions. This definition, in the best case scenario, will likely lag behind what clients implement.

As we cannot determine what is relevant 'metadata', I've given this section only two options: "never" or "when client hints that we should log this". That way, the client gets to decide (and we do not have to).