[Standards] Proposed XMPP Extension: Inbox

Andrew Nenakhov andrew.nenakhov at redsolution.com
Fri Jan 24 12:48:28 UTC 2020


On Fri, 24 Jan 2020, 03:50 Thilo Molitor, <thilo at eightysoft.de> wrote:
>
> You forgot to mention one notification type which is particularly useful in
> this context:
> You can use a Notification Service Extension to modify alert type notifications
>
> before they are displayed to the user.

I didn't forget it, I described it as the only available option (that
bit about encrypted payload was referring to exactly Service
Extension). I just didn't mention the method to avoid unnecessary
details for the wider audience. Maybe I wasn't completely clear cause
I described the 'end' model of a push service integration that should
work well for all types of messages, including calls.

> You can fetch the content of the notification from the xmpp server mam/inbox/
> whatever and replace the dummy content of the notification by the actual
> content.

Well, not really. Service Extensions come with A LOT of restrictions.
First, you can't access your main app code which leads to necessity
implement all in an extension. You have restrictions on access to app
data. The system tends to guard resources, killing off service
extensions that runs beyond the invisible lines. Use too much (on an
unknown scale) processing power - killed. Use too much memory (again,
it is unknown exactly how much is too much) - killed. Even the 30
seconds limit to connect to a server to do fetching is much shorter in
practice. Starting from iOS 13.2, the limit seems to be around 5-7
seconds. Also, you absolutely can't use this extension to initiate a
call: at best, you can display an alert, 'incoming call from Vasya',
which you can't dismiss when the call is cancelled by a caller, on
which a user must press to activate an app, which must then connect to
a server, and do the real call initiation. Think of 25-30 seconds
delay, or maybe 20 seconds, in best case scenarios.

This said, Service Extensions is the only available option to move
forward. We are thinking about extension to a server, where a client
receives an encrypted payload containing a message ID. The client will
decipher this payload, retrieve the ID and then connect to an XMPP
server with a special short type request that will fetch that message
by ID (Actually, it would be easier to implement using good old
HTTP!), and then present it to a user, or dismiss an alert if it was
already read. We'll likely test this approach in a few weeks.

And If we want calls, it is an absolute MUST to couple it with VoIP
pushes. Which leads to a 'smart' push server and smarter push modules
in XMPP, which can distinguish between different types of outgoing
push requests.

> By using something like "bad network connectivity, message could not be
> loaded" as the dummy/fallback content of the notification the UX would not be
> that bad either.
> As far as I know Monal is using a Notification Service Extension to display the
> message content in notifications without using VoIP pushes.

To be honest, we never ever had any luck running Monal. After this
email we downloaded it *again*, it didn't register for push
notifications on any of our accounts on any of our devices on any of
our servers (they run mostly latest ejabberd now, so likely they have
some non-standard XEP-0357 implementation). Maybe we're doing
something very wrong with it, but 'Monal Push Server' just never
activates.

Also, I beg to disagree on 'message could not be loaded' notification
being not that bad. Whatsapp, Telegram, Signal, and even Matrix client
are all exempt from such problems. We, too, can either solve them or
settle for mediocrity. I'd rather attempt to do the former.



--
Andrew Nenakhov
CEO, redsolution, OÜ
https://redsolution.com


More information about the Standards mailing list