After testing Siskin and Monal for a few days, my impression is that XMPP is now way more usable on iOS than it was back in the days. Many thanks to @tigase for their great work on Siskin IM.
@held No, it's not normal. Do you have any other client connected? Do you have any additional prosody configuration? Have you checked in prosody logs whether it forwards typing notification to push server?
@tigase I had chatsecure and monal on that device as well, but now both are uninstalled. However, prosody shows a push registration for this client for all three push servers in its log file. I know, you're no prosody support, but do you know when these push registrations will be deleted from the server?
Self-pushing while typing still occurs... I have no additional push config added to prosody except the enabling of mod_cloud_notify. Should I provide the whole config?
@tigase... and muc pushes stopped working from yesterday to today. The checkbox "push notifications" in the muc settings in Siskin can not be enabled...
@held they stopped working for all rooms on all servers or there are only certain rooms? In general whether you get or not a notification highly depends on your server - whether it generates one or not. However, MUC (especially on mobile) is quite broken, because once your client looses connection (which on iOS is the default state) then you are not in the room, which causes problems. There are various workarounds but we are working hard to make MIX reality in XMPP world :-)
@held I don't know about retention of those push-registrations. In case of siskin it's not possible to remove account without disabling push.
As for self-typing notification this is definitely weird - does it happen always or only on selected chats / groupchats? Could you check prosody logs whether prosody forwards those stanzas? In general Chat States (https://xmpp.org/extensions/xep-0085.html) should not be forwarded to push.tigase.im
@tigase the prosody - guys call the self-pushing a "a really interesting issue indeed" 😂 and also have no fast solution to it. It happens in all chats, except mucs (not surprising, since pushes do not work there at all currently).
Edit : even if the push activation slider in muc still can not be enabled, muc pushes work currently (no idea what changed in the mean time). Self pushing still occurs in chat, but not in muc
@held I can recommend checking prosody logs and trying to figure out what's triggering forwarding to push.tigase.im :-)
@held btw. MUC push in siskin will only work with Tigase XMPP Server (for now) - the area of MUC for mobile devices is quite "wild west" but we are working on making it more workable :-)
@tigase just to clarify that: muc pushes work perfectly for most mobile devices. Only the bizarre 🍏 causes problems. But thanks so far! I'll have a look on the logs once again, but the prosody guys mention that it looks more like a client / app push server problem, while I think, the biggest client problem is the 🍏😜
@held @tigase For 1:1 chat, push seems totally reliable to me: I haven't noticed a single case of missing (or duplicated) notifications with Siskin. MUC push notifications are problematic indeed (due to design/protocol issues, not due to Siskin bugs). This will probably work better with Monal once Thilo fixed Monal's MUC support (due to Monal going for a different design). The fix for Siskin is basically to have the server implement MIX.
@holger @tigase the monal muc support is far behind Siskin tbh (currently my 🍏clients use parallel chatsecure only for muc). Decisive downsides of Siskin during this test were a) the self-pushing (annoying, but not crucial); b) 1:1 omemo, which works with Conversations, but not with gajim (as far as I tested , and works with monal), and c) the missing muc push (since neither chatsecure nor monal are capable of this, that's no downside, to be fair)
@held @tigase Actually MUC push should work both with ChatSecure and (once it has proper MUC support) Monal, if the server keeps the session open for push clients. ejabberd ships mod_push_keepalive for that, and I think Prosody's mod_cloud_notify does this as well.
And yes to be fair I'm testing things without OMEMO. I think XMPP's ecosystem is not quite ready for enforcing E2EE.
@held @tigase @holger Anyway I agree that we're not quite there yet on iOS. I was just positively surprised of the state of Siskin. So I think things look much better than a few years ago. Back then you'd see message loss and dups and whatnot. Those were the hard problems, and they seem fixed. Things such as MUC push and OMEMO are still to-do, but back then the to-do list was like "push, OMEMO, and tons of other issues".
@holger @tigase I think e2ee is a must have nowadays, at least in 1:1 chats. But you're right, the progress of monal and Siskin is pretty good!
According to the muc pushes: my prosody with cloud_notify is never pushing monal clients and not reliably pushing Siskin clients on muc messages. Sadly, I'm just a private server operator, neither developer nor professional IT staff, so my competence and time for solving issues like that is limited 😜
@holger @tigase... but federated e2ee would be so much easier if some fruit company wouldn't constantly sabotage all federated attempts... But that's another discussion. And this behavior grows at Google as well...
Just read a bit about MIX. Looks interesting! Let's see if and when the rest of the ecosystem is supporting it as well.
@holger @held just to clarify - in Siskin we expect that the muc room will send messages to user's server and it will forward them (if needed) to push server without the need to not-closing the stream (which has it's own problems). In Tigase we achieve that by users registering to the room (using method defined in MUC specification: https://xmpp.org/extensions/xep-0045.html#register), so MUC can send messages even if the user disconnects. This is somewhat similar to MIX and MucSub from ejabberd (which also resembles MIX)
Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.