[12:29:54] <Wójcik Andrzej #>

                        if (packet.getElement().getChild("received", XMLNS) != null ||
                                   packet.getElement().getChild("sent", XMLNS) != null) {
                             return;
                        } 

[12:35:22] <Wójcik Andrzej #> niestety XEP-0184 i XEP-0280 definują element received ale z różnym namespace, przez co ja unikając kopiowania received z XEP-0280 nie sprawdziłem XMLNS i wyszedł ten problem że ignoruje received z XEP-0184

It looks like the code which I thought was not working properly is actually working just fine. However, to make carbons be created, packet type needs to be chat and it must not contain no-copy message hint nor private element with carbons namespace. Could you check what is actually sent when carbons are not delivered properly? My guess would be missing type attribute value but I do not recall actual situation which we discussed.

Andrzej Wójcik wrote:

It looks like there is no issue here. Message carbons are only created for messages of type chat while received messages are sent without type being set.

This follows https://xmpp.org/extensions/xep-0280.html#which-messages but - this list is only suggestion so, for the sake of having something convenient (i.e. read status propagated to all client), also forward carbons for receipts? %kobit %bmalkow what do you think?

@wojtek

See below extract from XMPP mailing list from a few days ago:

On Donnerstag, 25. April 2019 21:09:04 CEST Georg Lukas wrote:

• Kevin Smith kevin.smith@isode.com [2019-04-17 20:28]: PR #779 - XEP-0184: add a box about types and JIDs - https://github.com/xsf/xeps/pull/779> This seems a little backwards to me - it?s only saying the completely non-normative 'is a good practice? for doing the right thing, while saying ?should? (yes, I realise lower case) accept the wrong thing. Should we not SHOULD doing the right thing?

You've done a good job of hiding this remark (even from me), and the topic didn't fit into our last Council Meeting, so pulling this back up on the list, with a greppable subject.

The rationale for #779 was not to change normative language while providing additional value to new developers.

If you prefer to have normative value-add, I'd replace the figleaf-box with something akin to this strawman text:

---

The receiving client should consider the following when generating a Receipt, depending on the message type of the message that contained the Receipt Request:

• "chat", "normal": the Receipt message SHOULD have the same @type as the Request message.

• "groupchat": it is NOT RECOMMENDED to request Receipts in a MUC. A client choosing to respond despite of this SHOULD send the Receipt with type="groupchat" to the bare JID of the room and not to the full JID of the sender. It MAY be useful to limit this feature to private MUCs with a small number of participants, or to instead send the Receipt as a MUC-PM.

• "headline": the Receipt message SHOULD have type="normal".

• "error": this should not actually be possible, so the client SHOULD NOT (MUST NOT) respond.

A client MUST be able to Process a Receipt message with a different type than the original Receipt Request message.

However, this is obviously a normative language change to a Draft XEP and so I didn't dare to do it, initially.

This sounds good to me, except for the rule for "headline". I have no idea whether that?s good or bad. In other words, I?m fine with the proposed wording far enough that I think it should be proposed as an item to vote on (and I?m tending strongly towards +1).

which suggests that clients should respond with the message of the same type which solves this issue, right?

Andrzej Wójcik wrote:

which suggests that clients should respond with the message of the same type which solves this issue, right?

In theory - yes, but this requires client to actually follow it (and this is still "recommendation".

IMVHO we could still handle this on the server and make it work for any message type.

To be honest if user would be offline, then thanks to MA/MAM/Offline Message Delivery it will be delivered to all clients, so we should apply the modification which @wojtek suggested.

I've made a modification and verified that it works for me. Please check it on your own if everything works for you as well.

Fix is ready for deployment

Deployed:

componentInfo{Title=Tigase XMPP Server, Version=8.1.0-SNAPSHOT-b5401/0b2130b8, Class=tigase.server.XMPPServer}
componentInfo{Title=Tigase XMPP Server Distribution, Version=8.1.0-SNAPSHOT-b10282/f585f1a4, Class=tigase.dist.XmppServerDist}

It works but… it doesn't solve the original problem - you have two clients (let's say desktop and mobile), you receive the message, both devices create notification and marks chat with unread count (and at this time delivery receipt is generated). Now you open the chat on one device, it clears the unread status on that device but notification/unread status persist on the other devices.

But it looks like there is not XEP that could handle this use case...

On the server side now everything works as expected.