Push notifications

[DanielOaks]

Let's do some weird interesting stuff and see if we can get this working in any reasonable way at all, whoo.

The only prior art I know of for this is Palaver's iOS push notif capability: https://github.com/cocodelabs/palaver-irc-capability/blob/master/Specification.md

What are our requirements for something like this, and do we have any clue what it'd look like?

Rough requirements:

• iOS + Android
• Any other mobile OSes do push notifs? Can we make this flexible enough to be pluggable if any new systems do come around (e.g. ios vs google or something with a data blob that gets defined for each system).

In the v3 channel, sling mentioned something about push notif clearing. How can we do that nicely, and can we just clone how the palaver cap does it? If so, mad.

Another rough requirement:

• Push credentials (iOS push-notif app sending key or w/e) needs to be provided by the app, and not by the server. Because jesus christ servers will absolutely not bother doing any of that kind of setup themselves, nor should they have to. The app author already has to worry about that stuff since they're working with the platforms directly.
• Do we need to define a 'standard http push endpoint' or something, and have clients provide us an api to push stuff to? See how the palaver spec does this - they do it for a reason that's probably related to the above point.

So, what does this look like in our heads?

[DanielOaks]

tbh since palaver has a working implementation of this, cloning theirs as much as possible (at least for the ios side of things) is a very sensible way to go about this. maybe ask if they've had any issues with their system so far / any requests / anything that they would like to change?

(optimally, we'd just be able to provide a simple forward of the PALAVER command/cap to our system as well if our impl matches their one fairly closely)

[DanielOaks]

+1 rough requirement, we really want to encrypt message contents before sending 'em through the app's infrastructure, if the app does need to send it through to the platform. I remember the convo about where you could do that was messy and all over the place back when we discussed it in v3 a few years back, but if we can get some concrete docs saying yes/no on whether apps can process incoming push notif contents (and decrypt them) before displaying then mad.

encrypted with some key the app/client knows but hopefully the app infra that sends the push notification to <platform> doesn't know would be grand.
https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension

[DanielOaks]

So, current differences between palaver spec and what we want to do:

1. Add Android notifs. This'll be a case of probably seeing what kind of information android notifications require, and adjusting the 'contact blob' to suite. Though, it feels like that won't be much at all. Or, since the HTTP endpoint that we're going to be reaching out to (to send the notif through to $platform's services) is provided by the client, maybe they could just provide us with some opaque blob of 'credentials' that we feed back to the http endpoint as-is, so the server doesn't even know what the credentials are? (and so that this spec can keep working no matter what weird extra requirements or changes the platforms do to their push notification endpoints). honestly it feels sorta like the palaver spec already accounts for this, so... probably no change needed here?
2. Don't send raw message through the provided http endpoint. Either:

• We send a message ID, and expect the client to reconnect+CHATHISTORY to get that message once they receive the push notification, or:
• We encrypt the message and send it encrypted, probably returning the encryption key/info/etc to the client so that it can decode the push notification content locally (and all the client's http endpoint sees is an encrypted blob).

On (2), kylef says this: "from a background device/battery life/network usage perspective, going down the route that the notification already has everything it needs (in some form, whether thats encrypted or not) is perhaps going to be the easiest".
We seem to agree with that, and the restrictive OS decisions (how much apps can run in the background for, how restricted you are in terms of post-processing, etcetc) really seem to push the 'encrypt and decrypt' way over the 'ping and pull' way.

So this is likely going to become a case of going through and deciding exactly which encryption/decryption method to use, how to share the secret between client+server, how often to renegotiate the secret, etcetc.

[Mikaela]

Any other mobile OSes do push notifs?

Ubuntu Mobile appears to do them https://phone.docs.ubuntu.com/en/platform/guides/push-notifications-server-guide

SailfishOS seems to not have them https://forum.sailfishos.org/t/what-apis-are-missing-from-harbour/4017/22

[slingamn]

Android web push encryption:

1. High level description: https://developers.google.com/web/updates/2016/03/web-push-encryption
2. Spec: https://tools.ietf.org/html/draft-ietf-webpush-encryption-09

This is maybe a little overcomplicated but it has some nice properties, in particular, partial forward secrecy: the server has no long-term key material that can be compromised (since it generates a new ECDH keypair for each message). However, the client holds a long-term keypair that is sufficient to decrypt past messages.

I'm tempted to simplify this along the following lines: all messages are encrypted with XChaCha20-Poly1305, using a symmetric key that's generated by the client and transmitted via the secure channel, and then the client can rotate it when desired.

[slingamn]

The threat model here requires a coordinated compromise of both the server and some component of the push infrastructure (either the app's server or the mobile framework's), which doesn't seem too concerning.

[slingamn]

The web push spec includes a recommendation to allow padding, to prevent bicycle attacks.

[slingamn]

It's worth looking at what Signal-iOS is doing; AFAIK Signal makes a point of only sending pings, no message data.

[kylef]

In terms of the prior art in Palaver's push spec, here's the things I'd consider could do with re-thinking:

1. Ignore nicks should become hostmasks (*!*@test.com). These should match and behaves the same as other matching in IRC (matching bans +b and exclusions).
2. Ability to specify (and perhaps on a per-channel basis) the specific commands that notifications should occur for (there are competing views on NOTICE being irelevant or relevant for notifications I've heard competing use-cases from users). KICK, INVITE, MODE changes etc. You may desire notifications if you are kicked or invited to a channel.
3. The matching rules with MENTION-KEYWORD, MENTION-CHANNEL, MENTION-NICK and exclusion (IGNORE-KEYWORD, IGNORE-CHANNEL, IGNORE-NICK) is a simplistic view which doesn't let you construct more powerful rules for notifications that may be desired. For example, I want a more complex set of rules to exclude (or receive) notifications using expressions (.and(.hostmask("zeta", nil, "example.com"), .keyword("IMGUR"))).
4. Matching for account names, matching for bots (+B mode) etc. I've seen various use cases that have come up over the years.
5. The regex uses for matching keywords is based on word boundaries, this makes sense for many use cases and how nick mentions work but this makes it not possible to write more powerful rules such as I want to get notified for messages that match ^LINK: in a staff channel.
6. Notifications snoozing and disabled hours (i.e, how can I configure a way to not receive messages in early AM or weekends for channels which are more "work" orientated).
7. Being able to from a notification say "snooze" on the thread or channel for a time period can be useful for spam or noisy occasions.
8. This isn't a use case from me, but I have had feature requests to have different notification sounds for different channels or senders.
9. I've also seen feature requests to have notifications when certain people come online (defining notifications for MONITOR targets)

One design note here is that people do want to configure notifications differently per device which is why these preferences are "device" specific not client specific. The protocol implements a preferences system and a versioning system so that we do not negotiate with the server all preferences for each connection.

The biggest use case that has come up is replying to messages or accepting invites from notifications directly. Connecting to IRC in the background to do this is complicated and may have side effects (such as bouncers like ZNC clearing history, or presence changing on traditional IRC, resetting AWAY state and idle information). This also gets complicated when it comes to having multiple active connections at once (you reply from notification on watch while using IRC on a phone). Launcing the entire application and bringing up IRC connection is slow (lots of handshakes/MOTDs/buffer's may be received automatically) and can have CPU and battery imact. I've been looking for a lighter way to send out of bound messages without bringing up an expensive IRC connection (capability negotiation is also a negotiation which gets slower and slower on high latency connections as more capabilities are needed like echo-message, batch, labeled-response, sasl etc).

Having a way to send IRC commands (with labled response) over HTTP was the solution I was hoping to bring. I've started defining this in the past at https://gist.github.com/kylef/ad79980a6ebe2e23a2862cfedbd62f8b. Another design goal was to be able to send messages from iOS share sheets too (such as from other third party applications). This HTTP based protocol would work by exposing a URL in isupport and some way to authenticate to the account or session to be able to send IRC messages and receive the response.

In doing so, I have also been rethinking notifications to be more generic. Instead thinking of them more like web-hooks in other services. For example in GitHub I can say that I want to receive a hook for opening a pull request or pushing to a branch. Twillio I can get a web hook for an SMS or a phone call. I was heading in the direction where we can solve push notifications in a generic way with web hooks which then opens up to more use-cases and makes the system less client specific. IRC bots along with many other tools can also make use of this style to be able to hook into receiving messages matching some expression (in a specific channel with a certain message prefix).

[slingamn]

Thanks, this is very helpful.

It sounds to me like most of these filtering rules belong in the client, rather than in the server --- i.e., the server should accept a relatively simple list of rules to generate an inclusive set of notifications, and then the client can decide which ones to display? This allows more flexibility around UI choices and more customization. (It also strengthens the case for including message content in the notification itself, rather than sending a ping; the client should be able to make the decision about whether to display the message without contacting the server.)

As discussed on IRC I think we should investigate #1420 as an optimization for the handshake (I think the objective should be for the typical client and server responses in the typical handshake to be smaller than the typical mobile network MTU).

[DanielOaks]

@slingamn I believe one reason to do the filtering rules before the client is because Apple does limit how many push notifs devices can receive, so if we're mixing both useful (actual pings) and non-useful (not actual pings) push notifs then we're likely to run into the issue of the client missing legitimate pings (see https://developer.apple.com/library/archive/technotes/tn2265/_index.html#//apple_ref/doc/uid/DTS40010376-CH1-TNTAG23 for more details). But that said I'm not super literate with Apple iOS documentation-speak so if actual iOS devs have input there then cool.

Thinking about that issue made me think "hey these should just be implemented in the client's http gateway instead, cool!!!" but with the encryption stuff we're doing yeah that's kinda impossible.

[DanielOaks]

Note to self re validating that we're not just DOSing some poor site out there, I imagine the network could just plain and simple keep a list of allowed gateways in it. Gives the network control over the clients it supports in this kind of way, etc. e.g. palaver.com, etc, etcetcetc.

Feels like something the networks may want to take ownership of.