The current state of #XMPP 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 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)
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.
@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.
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.
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.
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.
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!