[Standards] MAM: Conflicting storage prefs behaviour

Matthew Wild mwild1 at gmail.com
Tue Feb 21 08:34:06 UTC 2017

On 20 February 2017 at 20:47, Ruslan N. Marchenko <me at ruff.mobi> wrote:
> On 19.02.2017 22:49, Matthew Wild wrote:
>> An example implementation of storage de-duplication, let's say you
>> have two users: userA and userB.
>> userA sends a message to userB, which the server archives, because
>> both of them have archiving enabled. When processing the message from
>> userA, the server gives the stanza a unique ID and stores it in a
>> global stanzaStore. It then adds a record to userA's archive, which
>> includes the ID of the stanza in the stanzaStore.
>> When delivering the stanza to userB, it adds a record to userB's
>> archive, and with the same ID in the record. Both users now have the
>> stanza "in" their archive, but it is only stored once, in the server's
>> central stanzaStore.
>> Now userB decides to disable archiving (with userA, or with all
>> contacts, it doesn't matter).
>> The same thing still happens as before, but this time no record is
>> added to userB's archive. If they perform a query, no messages will be
>> returned. They are still stored (because userA requested that) but
>> userB cannot see them.
>> Does this make sense?
> Yes, thanks for the hint Matthew, so basically we still trigger the
> archiving per account, however on first archival of any given stanza we add
> meta-field to the stanza saying it's archived (eg. UID).
> So later if any other user account's prefs fit archiving condition for the
> stanza - we just store a reference - because we see metadata saying it's
> already stored.
>> XEP-0313 explicitly does *not* allow you to prevent your contacts
>> archiving your messages (this is impossible to do), so if you contact
>> has archiving enabled and you don't want that, there is nothing you
>> can do. The preferences in XEP-0313 are only about controlling *your*
>> archive.
> Yes, that's clear, I was rather asking whether archiving more than requested
> (or ignoring user prefs to archive what it asked not to) would be considered
> as violation of the idea of the xep or it's acceptable behaviour.

There are some deployments that will need to always archive things,
e.g. some businesses for auditing and compliance with regulations.
This is the only reason I can see to ignore the user's preferences.

I have always considered this kind of archiving separate from MAM. A
service that does this kind of archiving may want to keep the
"auditing archives" invisible from users, or they can implement MAM as
an interface to these archives. But in this case the interface would
be read-only and probably wouldn't allow any preferences.

I don't see a case for a server implementing support for preferences,
and then choosing to ignore them.

> On a last note - these prefs are supposed to be non-volatile or being
> session object and set up during each session initialisation? Since client
> will likely try to resync the archive - it will also likely try to resync
> the prefs.
> So question is probably more in the area of whether or not to archive
> offline messages.

The prefs are persistent, and yes, messages should be archived even
when the user is offline.


More information about the Standards mailing list