Project

General

Profile

uniquely identifying messages for status receipts between XMPP sessions

Alen Ilkov
Added about 3 years ago

Hello,

I am implementing message status receipts for a custom system with tigase v 7.0.1 as the XMPP server.

May be missing something fundamental here, but in the simple case of

-A sends B messages while B is offline.

-B connects, gets messages & sends receipts.

-A logs in and gets receipts.

how are the 2 peers expected to understand each other with respect to the messages they are referencing without access to persistent message IDs?

I am pretty close to deploying a separate database to keep track of those but having a parallel database presents its own set of challenges & upkeep. I can't imagine that I'm the first one facing this issue.

(This is a follow-up to the exchange that happened here:

https://projects.tigase.org/boards/19/topics/6077?r=6084

but has become a different question in light of the exchange.)

Thank you,

Alen


Replies (2)

Added by Alen Ilkov about 3 years ago

Think I understand how to provide the message status considering the limitations without a redundant db.

Using a combination of message timestamps and peer chat state, I can provide message status receipts locally without relying on XMPP's message IDs and receipts.

So if A is in a conversation with B including 100 messages without feedback, then when A re-connects, I can provide/proxy message IDs to A as index values (messages idx/id 0 through 99).

And if I timestamp B's last active chat state (active/composing) and last inactive chat state (paused/away/xa), then I can correlate the 2 with A's message IDs (which will not be guaranteed to persist between sessions) and assume the latter means messages were delivered (client was connected & receiving) and former means messages were read.

If B was last active when message idx/id 70 was sent and last inactive but connected when message idx 90 was sent, then those are the last read and delivered messages respectively.

When both users are connected, the interaction is a simpler use case.

I would appreciate any feedback, especially if I am missing something or any feedback at all from more experienced XMPP integrators & users.

(In case I have not made it clear, my server is aiming to provide a variety of services to FE clients, including those backed by an XMPP server, but they do not talk to XMPP server directly.)

Added by Wojciech Kapcia TigaseTeam about 3 years ago

Alen Ilkov wrote:

how are the 2 peers expected to understand each other with respect to the messages they are referencing without access to persistent message IDs?

Assuming you are referencing XEP-0184: Message Delivery Receipts it states in Protocol Format that:

Note: A sender MUST include an 'id' attribute on every content message that requests a receipt, so that the sender can properly track ack messages.

Tigase stores complete stanza (including message ID) into offline repository therefore it's possible for the other party to send ack for each stanza.

    (1-2/2)