Use the user (or room) JID instead of the server JID for the 'by'
attribute of <stanza-id/> and <archived/> tags. That's what the
examples in XEP-0313 v0.2 and XEP-0359 v0.3.0 suggest.
XEP-0313 says: "a server SHOULD include in a user archive all of the
messages a user sends or receives of type 'normal' or 'chat' that
contain a <body> element."
The "assume_mam_usage" option now takes a boolean value. Setting it to
"true" has the same effect as "if_enabled" had before. The "on_request"
behavior is no longer offered, as it made the option (and its
documentation) overly complex.
Limit the number of messages returned for a given MAM request even if
the client didn't specify an RSM set (not just if the client specified
an RSM set without a limit).
This is still not done for MAM v0.2 requests though, as that version of
the XEP doesn't require clients to support RSM.
- Change order of the hooks in mod_mam for sending and receiving packets. Messages are archived before a carbon copy is send to the other recourcces.
- Add archived tag and unique stanza id to the outgoing packet to have message carbons with the archive information.
- Add additional hook (in mod_mam) to strip the archive tag for outgoing packets after message carbons have been send.
XEP-0313 says: "A MUC archive MUST check that the user requesting the
archive has the right to enter it at the time of the query [...]. In
the case of open MUC rooms, the MUC archives can generally be accessed
by any users [...] who do not have an affiliation of 'outcast'".
Include the occupant JID with MUC MAM messages if the room is not
anonymous, and also when the MAM user sent the MUC message himself (not
just in the case where he is a room moderator).
Strip any pre-existing <x/> tags which have an <item/> child with a
'jid' attribute from MUC MAM messages. This way, if such a tag exists,
clients can be sure it was added by mod_mam.
If a stream management session times out for a user who appears to be
using MAM, drop any unacknowledged messages rather than resending or
bouncing them. This avoids duplicates or bogus error messages.
However, this is only done if the new mod_mam option "assume_mam_usage"
is set to 'if_enabled' or 'on_request'. In the former case, a user is
assumed to be using MAM if archiving is enabled for his account. In the
latter case, MAM usage is assumed only if archiving was explicitly
requested by the client, or if archiving was enabled by means of
mod_mam's "request_activates_archiving" option.
Sort the messages retrieved from an Mnesia archive before selecting the
subset limited by the <max/> value. This makes sure the desired subset
of messages is sent to the client.
If the client doesn't specify a maximum number of messages to retrieve
per page, set a limit of 50 messages. If the client specifies a limit
larger than 250, cap the number to 250 messages.
These limits aren't enforced for MAM v0.2 requests though, as that
version of the XEP doesn't require clients to support RSM. The newer
revisions say that "a server MAY place a reasonable limit on how many
stanzas may be pushed to a client in one request. Whether or not the
client query included a <set/> element, the server MAY simply return its
limited results, modifying the <set/> element it returns appropriately."
If an <index/> is specified in the MAM request, reject the request
rather than ignoring the desired index and returning wrong results.
XEP-0059 says that the server "MAY return a <feature-not-implemented/>
error."
