Let me state that this issue is a result of different behaviours of XMPP server implementations (all supporting XEP-0357: Push Notifications).

This issue should be "fixed" (or at least mitigated as this is additional workaround to deal with custom behaviour of a particular server implementation of this XEP) when a new version of Push component will be deployed.

Currently, there are different conceptions of marking push notifications as important (caused by a message with a body) and less important. (sending or not <x/> element, or not sending just last-message-body field in a form). That mixed with a different behaviours of XMPP servers related to privacy settings is causing this issue.

In my opinion, this issue was caused by developers trying to solve issue they faced by "using" things specified by the XEP in "creative" way, instead of/without adding a proper flags to make it obvious what they intend to do.

We have prepared a XEP-like document https://xeps.tigase.net//docs/push-notifications/priority/ stating shortcomings of XEP-0357 and suggesting a solution for them. Tigase XMPP Server and SiskinIM (including its push component) follow this specification and we are in progress on converting this "internal" specification into a document which could be converted into a XEP one day.

BUT: for sake of compliance and interoperability ther should be a solution which doesn't result in the above described behaviour as in this case by using a prosody-server I cant recommend anybody to use siskin as he/she will be spammed be push-notifications.

For the sake of compliance that should be standarized and specified so that all servers follow the same specification and have the same behaviour without client developers needing to guess how the server will behave and what to do with that.

OK, thanks for making your point clear (again). Hope from Prosody-side there will also any statement or solution.

Could you imagine to realize at least a short time workaround (within days/weeks?) until a long-term solution (months? years?) is found? E.g. that tigase push-server doing a temporarly filtering if the (maybe faulty) push-marked messages really are a push message worth (thus are having a real payload)? Or is this technically not possible?

I hope in parallel also a workaround on prosody-side is implemented. Only then this combination (Siskin, Prosody) could be called usable again.

And: what is the reason, that my siskin contact has tostare to six DIFFERENT push notifications - other way round: why they are not bundled to one notification to at least not clutter the display that much? At least I know this from Android/Conversations. Cheers, Robert.

As I've already wrote:

This issue should be "fixed" (or at least mitigated as this is additional workaround to deal with custom behaviour of a particular server implementation of this XEP) when a new version of Push component will be deployed.

As for

And: what is the reason, that my siskin contact has tostare to six DIFFERENT push notifications - other way round: why they are not bundled to one notification to at least not clutter the display that much?

SiskinIM groups notifications based on the "sender of a message" which unfortunately due to privacy policies is not sent by servers other than Tigase (we use encrypted push notifications, so message text and senders JID are safe). Due to that Siskin IM is not grouping those notifications at all as it cannot determine if they are part of a single conversation or not.

This issue should be "fixed" (or at least mitigated as this is additional workaround to deal with custom behaviour of a particular server implementation of this XEP) when a new version of Push component will be deployed.

Is there somewhere we can view the status of the deployment (or get notified when it has been deployed)? One of my friends would like to switch to Siskin once this is mitigated.

Mentioned "fix" should be already deployed for some time.

You said the fix is already deployed - in which version of Siskin we should find it exactly? And this means, that a Conversations message via Prosody should only produce ONE message on a siskin-IM client (instead of 6 what I stated above) - right?

Wonder why this improvement is not communicated here and only found out via direct question by @gjabell

Would you/anybody be so kind to point to any place where some further details can be read about (or maybe give them here) as it would be also from interest for at least Prosody-devs.

But for sure thanks for the fix at all! Cheers, Robert

@therob84 It was not communicated as it was deployed on the server side without users knowledge and was a solution which supposed to work. That was done some time ago and some time after initial issue which was reported here and just slipped.

The only thing I can tell about this issue is that each server has its own way to mark that push notification is for a message with a content. Unfortunately, this part of the code is not publicly available.

As for the fix not being communicated, I suppose it is far better to fix the issue and not mention that than just not fix it at all. Users which are actual users will benefit from that as their IM clients would just work better.

better fixing than mentioning - you are right, of course! Thanks for that.

So then I will again check with my siskin-using contact if it works now. He is not supposed to to anything on his Siskin-user side, right? And with "server side" you mean the push-server to which the siskin-IM-client communicates in all cases, not the used XMPP server of the account (which is prosody in this case), right?

Yes, you are correct. The "fix" was part of the push-server update.

So then I will again check with my siskin-using contact if it works now.

I can confirm that now only one push-message is received by Siskin-IM. So issue could be closed - or is there more to do right now? Thanks again.