Follow

The current state of iOS clients certainly leaves a lot to be desired. But I'm very excited about the rate of progress recently.

We now have a growing number of people making it their mission to ensure XMPP gets the first-class iOS experience it desperately needs.

Make sure to provide the developers feedback. If you find a bug that isn't reported, or that you could provide additional insight into, that is a really helpful way to contribute to improving the future of XMPP on iOS.

We can do this! 😎

@mattj Sounds interesting, but are the protocol problems solved? As long as push cannot be configured server side, there'll always be push spam. Matrix solved this pretty well, I would be really happy if XMPP could have as good push as Matrix one day. (iOS + Push + XMPP being as terrible as it is is what made me move to Matrix)

@mattj Also, as long as the server does not assign a unique id to every <message> that does not have one, there'll always be the duplicate messages problem when joining a MUC, as the client has no way of knowing they're the same :(.

@js
Modern MUCs all add unique ids to non-ephemeral messages 👍

@mattj Most recent Prosody release with Biboumi and I got no id on anything :(

@js
Obviously Biboumi is not a "native" MUC, but gatewaying to a protocol that has no concept of permanent message IDs. If you enable the bouncer/persistent mode though you'll certainly get stable IDs added

@mattj I did enable bnc mode and didn't get stable ids :(.

Also, when joining MUCs on other rooms (as in, not on my server), I also regularly did not get ids.

This made using any iOS client with push entirely unusable :(

@js
Are you looking at the sender-controlled id attribute perhaps? That's optional, specified by the sender and not the MUC, and not used for sync. The ID assigned by the MUC is separate.

@js
What kind of configuration are you thinking? What's your definition of "push spam"?

@mattj Join a MUC, get spammed, because there's a.) no filtering (I canot say don't push for MUC) and b.) no deduplication (if someone didn't specify an id on their message, I'm SOL)

@js
Not sure where deduplication comes in? The client would just ask for messages since whatever the last one it saw was.

I find this platform tricky for real-time technical discussions... if you want to chat, feel free to reach out!

@mattj The problem is that you get both, MAM and the MUC giving you the last N messages. If any of them does not have an id, the client doesn't know how to dedup.

@js
Modern clients don't ask for "the last N messages" but use MAM with IDs and/or time ranges instead.

@ij @mattj That doesn't work: That only means that if Siskin is connected, it will not notify when a message comes from this MUC.

If, however, Siskin is not connected and Apple Push is used, the server just sends everything, as the XEP has no filtering support, and iOS displays it. There is nothing Siskin could do about it.

@js
I'm curios: For Apple Push to be used, the Server would need to send the messages to Apple, wouldn't it? At least ejebberd doesn't provide such an option. So how Apple Push will come into the play at all?
@ij @mattj

@kirschwipfel @ij @mattj You need to send a message with a text via Apple. E.g. “New message”. This is what Prosody does. A client can then have an app extension to fetch and decrypt the actual message and replace the text. An app extension cannot however just dismiss a message (at least as of iOS 13). Hence server side support for configuring for what to send a push is necessary. Matrix does this, but there is no such XEP. Which is why push does not work properly on all iOS XMPP clients.

@js @kirschwipfel @ij @mattj sorry, tl;dr? I'm not thinking well enough to make sense of the details of the thread

@js
It's not quite that simple.

Filtering already happens - both the user's XMPP server and the client's push gateway do already make decisions about whether/what to push. Client and server devs are working on the best practices here. It's not clear that protocol changes are needed for this.

@kirschwipfel @ij

@mattj @kirschwipfel @ij Did I miss something? Last time I looked at the XEP, there was no way for a client to tell the server what to send push notifications for and filter by JID?

@js
No, there is no in-band way to configure a separate list of JIDs to what would normally be allowed to send you messages (if there is someone you don't want to receive messages from, block them!) I really don't see that as a primary problem.

Apart from this, the server and push server decide for themselves what should be pushed and what should not.
@kirschwipfel @ij

@mattj @kirschwipfel @ij It is a real problem, because you want to configure push *per JID*: Being notified about every message in a MUC vs. every message from a person is an entirely different thing. For some MUCs, I might want every message, for others only when I'm mentioned.

XMPP lacks any way to configure this. This is what made push on iOS unusable for me in the end.

Matrix solves this by letting you configure that per room.

@js
These two categories of MUC are generally easy to calculate: private groups can notify on every message, public channels only when mentioned. That gets the behaviour that most people expect without forcing them to configure anything.

Sure, it may not be 100% perfect, and power users will always want to configure, but it's a good enough default that doesn't require protocol or user intervention.
@kirschwipfel @ij

@mattj @kirschwipfel @ij Yeah, that would already solve the problem 90% or so. But I think in the long run, you want to be able to configure per JID - on the server, not just the client :)

@js I still do not get how/why a XMPP-Server will use apple push at all?!

Anyway, I'd call this a bug then, as using Apple Push betrays privacy. (Please be aware there is no such thing like "meta" data an apple can profile users by collecting timings.)
@ij @mattj

@kirschwipfel @ij @mattj Because how else would it talk to the phone when the app is not in the foreground?

@kirschwipfel @js @mattj There is a drawing of how Cisco Jabber does this and I think it's more or less valid for all implementations: cisco.com/c/en/us/td/docs/voic

So, there is the APNS and another server inbetween. For Monal it's ios13push.monal.im for Siskin/Beagle it's push.tigase.im. Usually you can see those connections in your server logs...

@ij @kirschwipfel @mattj Oh, Monal does iOS 13 push *finally*? I might try that again at some point - but now all my contacts moved to Matrix anyway, so hard to test 🤷‍♂️

@mattj It's nice to see XMPP development going well, with new projects like Snikket, Dino, and Kaidan, and even development on Gajim picking up again.
Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!