XEP-0313 MAM Implementation

[rufferson]

Carbons is good and well needed but there's tendency to shift towards MAM using it as subscription to pick up communication. Also it makes more sense to have it for mobile devices (sleep, wake, sync).

Any volunteers or perhaps even ready implementations? I have it on to-do list but not sure how fast i can approach it.

[noonien-d]

Conversations handles this pretty well in regards of de-duplication, synchronizing read status and so on.
For telepathy we'll need:

• Some way to get the last received message id from the logging daemon (or let gabble save it)
• XEP-0313 MAM for gabble
• XEP-0333 Chat Markers for gabble (XEP-0280+XEP-0333: Message Carbons and Chat Markers #3)
• Proper read status support in clients (send and remove notifications for messages that had been read on other devices)
• Also it would be nice to let the logger also handle receive- and read status for each message

[Kaffeine]

IMO it will be conceptually right to implement logger in connection manager (because the logger needs to know more and more details to work properly, see also TelepathyIM/telepathy-spec#1)

Proper read status support in clients (send and remove notifications for messages that had been read on other devices)

My summary:

1. Use MessageReceived on an other client message sent
2. Use PendingMessagesRemoved on a message read by an other client
3. Use the standard delivery interface for read status

I tried to use MessageSent for #1 and it turns out to be unsuitable for that. Also I realized, that a message sent by another client and then relayed by server is not different from a message sent by local client and relayed as a part of history (scrollback), so I recommend to use MessageSent only for messages sent by the local client.

[rufferson]

So far i was working only with qmlmessages/commhistd client implementation so was thinking should be sufficient just to emit Carbons/MAM messages with proper timestamp and flags on the normal text channel and they will be consumed and stored to history. And to trigger sync on a) connection apparently b) active state (that was my PoC idea). However yes now deduplication problem comes into picture as each MAM sync will potentially re-emit certain messages. and with Carbons the duplication almost inevitable (unless we make the properties mutually exclusive).

[ivucica]

• XEP-0363 MAM for gabble

Nit: The issue title is correct, this is XEP-0313, not XEP-0363.

[noonien-d]

Nit: The issue title is correct, this is XEP-0313, not XEP-0363.

fixed, thx.