XEP-0313 MAM Implementation

TelepathyIM / telepathy-gabble

XMPP connection manager based on telepathy-glib

https://telepathy.freedesktop.org

Other

12 stars 3 forks source link

XEP-0313 MAM Implementation #5

Open rufferson opened 6 years ago

rufferson commented 6 years ago

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 commented 6 years ago

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 (https://github.com/TelepathyIM/telepathy-gabble/pull/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 commented 6 years ago

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 https://github.com/TelepathyIM/telepathy-spec/issues/1)

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

My summary:

Use MessageReceived on an other client message sent
Use PendingMessagesRemoved on a message read by an other client
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 commented 6 years ago

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 commented 5 years ago

XEP-0363 MAM for gabble

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

noonien-d commented 5 years ago

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

fixed, thx.