XSF Discussion - 2018-12-17

Kev: A while back we were discussing silent APNS notifications, I think I promised to look up the docs on their unreliability. FWIW I now stumbled over them again: > APNs sends a limited number of silent notifications---notifications with the content-available key---per day. In addition, if the device has already exceeded its power budget for the day, silent notifications are not sent again until the power budget resets, which happens once a day. https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/sending_notification_requests_to_apns

Also the description of the `apns-priority` field, and this: https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_updates_to_your_app_silently

(But either way Daniel's suggestion to use this would probably do the trick on recent iOS versions: <https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications>)

Holger: how does that relate to the proposal of sending stripped down stanzas to the push server (only XML meta-data)

Ge0rG: As you probably know, Chris' solution is to use high-prio notifications which don't wake the app but generate a lock-screen notification instead (and pressing that wakes the app). So he was interested in getting more info regarding the stanza that triggered the notification, in order to not generate lock screen notifications for stanzas without message body.

Holger: I think that Anu is also working on content-modifications.

Holger: yeah, but the high-prio vs. low prio thing somehow escalated

and then it was buried for half a year and nobody remembers any more what the best solution was

With escalation you mean my stripped-down-stanza suggestion? :-) Chris' solution was/is basically to have the XMPP server distinguish between high/low prio, while I thought we might want to be more flexible in the future, i.e. for Jingle calls, MUC invitations, or whatever.

But if that content-modification thing does the trick, maybe we can forget about all that and get away with silent notifications after all. At least to get iOS working.

"Content modification" also allows omitting/removing the lock-screen notification altogether?

Holger: I don't know about the last point

Ge0rG: BTW I don't quite understand the story with Monal. I thought it has that VoIP flag which would allow for silent high-prio notifications.

Apparently it either doesn't use those or they aren't reliable either. Not sure how the VoIP flag helps then.

Holger: the latest Monal beta is working fine on yax.im, but apparently not on other servers.

Holger: not sure which kind of notifications it's using

Hmm.

the whole thing is super complex, as other XEP implementations also play a role (CSI especially)

Yeah, I'm into *that* part of the complexity, but I'm clueless what happens once the notification reaches push.monal.im :-)

Hi

What questions can I answer?

Anu: Hah, ignore my 1:1 messages then.

Hahah

The first question was whether you can delete / merge newly-delivered-notification, to which the answer was "yes"

Yes

Anu: what kind of information do you need on the push server to determine whether to send a low-prio / high-prio / no push message?

Holger: Sorry I’m just waking up over here

Anu: There's no hurry :-)

Anu: A while back you said that the APNS notifications you're using won't (necessarily?) wake Monal if it was swiped away.

Anu: But doesn't Monal have this VoIP flag which would allow for silent high-prio notifications?

The push channel on monal at least just a signal and is silent (on or off) the actual logic happens entirely in xmpp. The push is not the notification, the notification is generated by the client manually not the server. This is why I can look at older messages and modify

Right.

It only gets silent high priority notifications that resume/launch the app

Anu: I thought you can't have silent *and* high-prio in the same notification

Swiping away will launch monal but in circumstances where the device is locked, it is not able to unlock the encrypted keychain

That's the idea of using 'silent' APNS notifications, right? I understand that they're usually throtteld by Apple. But I thought they're reliable for VoIP apps. Nevertheless they don't seem to be reliable for Monal?

Ah.

Monal is a special case blessed by Apple :)

Anu: if Monal wasn't a VoIP blessed app, how would you work around that?

We need XEP-0357 to also work for the non-VoIP use case

If it weren’t the then the notification could still be silent but notifications will fail when the app is closed and in those cases the notification text should be generated by the server in a second notification

So either the message body comes in the notification’s payload

Anu: by the XMPP server or by the push server?

Yes

But since the whole design is the push server shouldn’t see the text

Anu: sending the message body over third-party channels is a security violation

Yes

so you'd have to send something like "You received a message"

`push_notification_important_body = "Important message";`

So the xmpp server would need to see if the message was fetched after x amount of time

If not send a second non silent push message saying “you have a messag”

Anu: shouldn't the push server figure that out?

i.e. XMPP server sends a message skeleton to push.monal.im, the push service attempts a silent notification and if that fails re-attempts with a "loud" one, if there was an actual message

Push server is largely one way

I'd rather not encode retry timing into the XMPP server

Failure does come on the apns feedback channel but that means the token is likely invalid

Apple is paranoid and rotates then

Anu: so there is no feedback about whether the app actually was notified?

Anu: it would be great to collect some numbers on how well silent vs. non-silent notifications work and what the delays are in practice

I think from user feedback it's obvious that silent notifications alone won't do the trick.

I don’t think so, they update it every year so I can take a look

Brb baby duties. Will be back in 30 min

As I said above I was hoping that this thing might do the trick (for iOS >= 10): https://developer.apple.com/documentation/usernotifications/modifying_content_in_newly_delivered_notifications

At least if it also allows for removing the lock-screen notification altogether.

Yeah an extension is just launching the app

Yeah an extension is just launching the app

The extension would be a new app

Sorry back

Baby

Technically the extension is th opposite of monal but should work and have a similar effect.

I am adding logic for where it can’t download

The only issue is that like most of the world things are http focused.

In the case of xmpp, the extension would be a new app that opens a new connection (and resource)

I have a share extension and wen through some fun hoops to hide that

I’m very interested in more feedback on pushes on monal, I have never had any fail. If notifications don’t show up it’s usually the case that the push arrives but monal does not download a message

Anu: or Monal can't resume the session for some reasons.

On jabb3r, yeah I’ve noticed this too but on yax it has

Thus the muc experience

Anu: were you able to pinpoint why it fails?

No, the actual

Interaction is identical

It tries to resume and then receives an error

I thought it was monal too but the past week of testing muc with yax

It seems not to be the case

Now that I know it’s not client side, will good to actually debug on jabb3r now

Georg: as you know from your iOS device, notifications come in ( in excess) :)

Anu: maybe Monal fails to resume within the 5 minutes timeout on jabb3r.org? I've got 30 minutes on yax.im ✏

With push the stream is supposed to never expire isn’t it?

I don’t think that’s true

that’s an implementation detail of some implementations (ejabberd)

it gives you a certain time until after the first push to connect

Ah

I *think* Prosody's mod_cloud_notify has a similar hack, but of course not all servers will have that enabled. (And either way there's still *some* timeout, just a longer one.)

Man push notifications are a pain

They are.

But why is the session thing so essential? I thought Monal supports MAM?

It’s really not that bad for other protocols

It's also not that bad on Android ;-) Because silent notifications 'just work'.

The diversity of configs and server software makes it really hard to deliver to consistent experience

Android isn’t really a privacy focused os though

So there’s a lot more wiggle room (and rope to hang with )

True. My point is just that I think the biggest pain here is the unreliable silent notifications.

Whatever.

Yeah

I think the notifications are working

If resumption fails, won't you receive the message from MAM?

The issue is client side

Yes

I don’t show notifications for mam messages

Ah, why not?

I would do that. You can't safely assume the message has been seen elsewhere just because you got it from MAM.

It was generating excessive notifications

So then you'd not have to worry about session timeouts, the experience will be the same either way. I think 0198 should just be seen as an optional optimization.

Hmmmm.

Yeah if the resume fails it just connects like normal

Why I am puzzled by people not getting notifications

Apns is officially best effort

But in about 8 years or working with it I have never seen a notification fail to deliver

I’ve seen delays

But that’s usually cell network issue

I think the APNS throttling tries to be magic in that it depends on various factors such as the app usage, the battery, and whatnot?

So I guess it might be normal that experience differs?

With haven't tested Monal too much (my test iPad somehow doesn't like it) but with ChatSecure I had missing notifications all day long until Chris switched to high-prio notifications (which work reliably indeed).

s/With/I/

Holger [14:30]: > If resumption fails, won't you receive the message from MAM? Except that failing resumption does the weirdest things to the messages in the SM queue.

Maybe, but that won't explain missing notifications/messages.

I mean, Monal not notifying on MAM messages would explain it I guess :-)

The right thing is to de-duplicate between local history, MAM and offline messages, and to notify on *new* ones

Except... you need to delay until you processed everything because you might have answered some of those from another device

And this is where you need a Ph.D. to write a simple XMPP client.

The latter behavior would be nice to have (where 'answers' could include chat markers/whatever), but that's kinda optional I think.

I think for the moment it would be good enough to (1) deduplicate using the stanza ID (no Ph.D. required) and (2) notify on all messages (MAM or live).

Not sure how notifications on MAM messages generate a flood? Maybe a full query of a large MAM archive for the first time or something?

Holger: (1) only works on private messages from clients that generate unique IDs; (2) ITYM "notify on *new* messages (MAM or live)"

Holger: if you notify on each message, you'll end up flooded

I mean the server's stanza ID?

Ah, so you mean the stanza ID and not the stanza ID. Yes.

Of course.

Sorry for my misunderstanding.

I.e. depend on mam:2 for deduplication (unless you have a Ph.D. and too much time).

So how do you deduplicate *sent* messages based on stanza ID?

Okay, (1) dedup incoming, (2) make your damn Ph.D., (3) dedup outgoing.

Some days ago, I received multiple copies of the same message from an IRC transport, and the copies (routed to different of my resources, of which one was offline) had different message IDs.

Also different stanza IDs

There should be a XEP describing how to dedup

I'd use one of the other IDs for outgoing. But yes that's not nice.

A reminder that xmpp is a brutally complicated protocol. :)

Super powerful but often conflicting

This is so sad.

Emergent complexity!

Emergency.

So on other protocols we’ve esp for mobile we’ve ditched the idea of being offline. Things are down based on devices registered

Deduping on a guid associated with every message

Anu: yeah, that's a great approach but XMPP isn't there yet

I just discovered how to query mam archives in reverse chronological order

Thanks Georg

That will probably help too

Anu: I'm not sure it's a good idea to query them in reverse

Ux

Anu: some messages contain back-references, like LMC

You want to see newest first and the pull the older ones later

Lmc?

Anu: so now you need to cache the newer message that references an old one until the old one has arrived. https://xmpp.org/extensions/xep-0308.html Last Message Correction

Oh fun

The problem with my current mam

Anu: okay, pulling in the last 50 in linear order won't save you from that

Is 90 percent of hemtime I use my phone

When I go to my iPad or laptop it starters to get every message since I last used it

Ge0rG: It's not mandatory to support LMC though.

Holger: nothing is mandatory. What's your point?

BTW, LMC would be a good addition to cs-2019, cc jonas’

And what I really care about is most recent, I can pull down to get more if I need more

Ge0rG: My point is I would not let my MAM retrieval strategy depend on XEP-0308.

If the original message isn't within the chunk I got from MAM, so be it. If the user scrolls up, he'll receive it. Probably. The server might've ditched it already anyway.

Anu: then you need to mark a message with an LMC for something that you haven't fetched yet and merge them when the user pulls down

Yeah

LMC is just one example of message references.

Basically some tie breaker logic

And my point would probably remain the same for any other examples.

There's no guarantee you get the original message anyway.

No guarantee, no.

So don't make XMPP life even complicater than it is anyway.

Yeah it’s based on age and archiving preferences

said the server developer.

Holger: quick question, monal works on the iPad 2 up

Basically every iPad but the original

What do you have? It should work for you

Anu: I can no longer reproduce the crashes. It seemed like it was triggered by some MAM message which is no longer retrieved (not sure why, I'll have to look).

There were a few ui glitches recently but I’ve been fixing those

Also I’ve fixed a lot of crashes

Ah yes I did update recently, maybe it was due to your fixes.

I fix them as soon as they come in to crashlytics and put our an update the same day

When I am working on it there is a release nightly for betas and weekly for prod

Very cool.

I'll have to look into the MAM thing but other than that I'm happy :-) Unfortunately I can also reproduce missing push notifications though---even with normal live messages.

2 week sprints, crashlytics is my feedback loop

Any particular server?

Now that it's no longer crashing, I'll be much better with looking at the traffic and things.

I'm using conversations.im for testing.

I realize all the servers I’ve tested with have been prosody, made a balbber.im account to test with ejabberd

On the betas there is a log at the bottom of settings, it’s the devices console

So it prints out the full stream and all errors there

New release coming out today btw

Right now I'm using the release, I'd be happy to switch to the betas.

I added muting becuae the notifications are a little too good esp with muc

Heh.

Switch to the betas on my website

Better if you are a developer

Anu: I suggest two things: - collect all new messages per JID/MUC until sync is completed - don't make notifications if you see recent activity from another device

https://testflight.apple.com/join/RjIlyvqa

Hmm

Might be the right approach

Anu: Installed, thanks.

If messsges fail to arrive take a look at the log, it’s pretty raw but you can see every stanza sent and receives

If you see anything wrong let me know I can usually have a fix up in a few hours

Yes that's very useful.

Awesome to see you being so active.

The more feedback the better, I can’t really test everything myself so it’s great when others let me know when they see bugs :)

Anu: did you implement LMC already? :D

Not in develop branch yet

Soon

It will be there soon though, I have a lot of feyures that I am sitting on becuase I need to put our bug fixes

And I generally dont do major features and bug fixes in the same releases

Ge0rG, re LMC + CS-2019: PR please?

jonas’: last time you asked for ML and not for PR :>

I don’t care, I take either

jonas’: any chance to demote Avatars from Core to Advanced? :D

hm, not sure

Mmmmmm, does Avatars depend on PEP+ / 222?

So now that Logitech is discontinuing XMPP support on their Harmony smart remote control, I first time hear about that support: https://twitter.com/smkelly/status/1074494850815455232

XMPP Marketing at its best

Funny I know a lot of iot devices use xmpp

Robot vacuums for example

It'd be great to fill the IoT page under https://xmpp.org/uses/ with specific examples, akin to Online Games; instead of a generic definition of what IoT is about

👍

I'm sure we've had that discussion before, and I'm sure I wrote an issue for it already, but I can't find it.

Zash, Anu: https://github.com/xsf/xmpp.org/issues/490

Guy on curl mailing list is asking for advice about how to implement 'push notifications' with curl as the client

Someone mentioned you could make a request and wait for server to respond, guy asked "but what if the server has something to send and the client has lost connection"

curl does xmpp now?

Inb4 re implementing xmpp poorly on top of http

No but I'm thinking of suggesting he use xmpp instead of http

BOSH?

isn't that the company that provided emission manipulation devices to Volkswagen?

Anu: could you add your vacuums to the issue?