Return receipt?

Is it possible to implement a return-receipt, thus having a list of users that confirm the receipt of a message?

I.e. User1 sends “Please do not feed alligators”

and then somehow he can have a list like this:

User2: read “Please do not feed alligators” at 2011-10-25 14:33 CEST

User3: read “Please do not feed alligators” at 2011-10-25 16:11 PCT

User4: read “Please do not feed alligators” at 2011-10-26 21:32 GMT+2

Use email And what about if use just closes your message without reading it? In email clients you have to check checkbox that you have received or read the message. Do you want the same in jabber? I see no point, but probably this is possible. If you want to be sure that your messages aren’t disappearing, then there is a special protocol for that, but Openfire/Spark doesn’t support it.

Hallo and thanks for your reply.

I agree with you, email is the instrument for that, but we are looking for a way to do this in IM.

No matter if the user mark as read a message even if he didn’t actually read it, it is on his own responsability.

I can’t give you any direct advices, not a developer myself. But i suppose you will need to modify Spark or any other client you use to propose a receipt dialog after every received message for a user to confirm, then that condiframtion will be automatically sent as a message to the sender. But it may get in to a loop (confirmation about the confirmation…). Maybe it is better to implement it both on the server and on the client, though this would be harder and you will have to recompile your own Openfire version to be able to upgrade to new versions.

I’m not sure if email is the right way to go but that’s another discussion.

But, to add to what wroot has said, you might want to take a look at xep-0184, xep-0198 and this discussion from a few years back to get an idea of how an ack solution could be implemented and what sort of obsticals you’d have to overcome.

Hope that helps,


Yes, and there are 3 tickets for Spark, Smack and Openfire (SPARK-1238, OF-434, SMACK-331). Somehow i thought this was about the “hidden” ack receipts between the server and the client, but it seems it is more like the “e-mail style”. Tickets are open, but probably will stay like that for a long, unless someone will provide patches.

Oh, and these ones are probably about internals acks between the client and the server: OF-446. SMACK-333.

Thank you guys, I think I’ll go for a hand-built solution, considering that we need only a system for sending messages groups-wide and to log users receipts, and possibly to integrate it into an existing application.

Thanks again