-
|
I have a question related to MAM query. So Whenever I send a message, I receive back only a stanza id, however, I cannot query MAM based on stanza id. I can query MAM for a specific user with either message afterUid/beforeUid(which is different from stanza id), or Date. I can get message Uid for received messages but I can't get it for outgoing messages. Is there any way to query MAM by stanza ID? If not then, how can I get a message Uid for outgoing message? |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 3 replies
-
|
You can use it is query rsm: This will return messages directly after id you provided. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your reply. This is how I send amessage with Smack(Android) As you can see, I set the stanza-id element, however, on the receiver side, I get stanza-id different(which is generated by ejabberd server). With the stanza-id I received on the receiver side, I can query MAM and it works perfectly. However, on the sender side, it is not working as expected. Is it possible to enable the ejabberd server to take my stanza-id instead of generating a new one on the server side? |
Beta Was this translation helpful? Give feedback.
-
That's currently not supported by the protocol. One issue would be that the server cannot blindly trust client-generated IDs to be unique (how to handle the case where multiple clients use the same IDs, or a single client reuses IDs, and so on). A pragmatic solution is to just query the history the last known stanza ID, and then de-duplicate known messages (maybe simply based on your client-generated message ID). |
Beta Was this translation helpful? Give feedback.
-
|
That is how I have implemented it right now. I would like to prevent getting duplicated messages. As I see there is not such an option for that. |
Beta Was this translation helpful? Give feedback.
That's currently not supported by the protocol. One issue would be that the server cannot blindly trust client-generated IDs to be unique (how to handle the case where multiple clients use the same IDs, or a single client reuses IDs, and so on).
A pragmatic solution is to just query the history the last known stanza ID, and then de-duplicate known messages (maybe simply based on your client-generated message ID).