make this an IRCv3 spec

[slingamn]

I am interested in implementing this in Oragono, but only if it's submitted through the IRCv3 draft process and no longer refers explicitly to Palaver.

A question: what do PALAVER BACKGROUND and PALAVER FOREGROUND do? I'm not clear on what the server is supposed to do with that information.

[slingamn]

Someone explained this to me --- is it that PALAVER BACKGROUND enables the push notifications, and FOREGROUND disables them?

[kylef]

A question: what do PALAVER BACKGROUND and PALAVER FOREGROUND do? I'm not clear on what the server is supposed to do with that information.
Someone explained this to me --- is it that PALAVER BACKGROUND enables the push notifications, and FOREGROUND disables them?

That's right, in the ZNC implementation you will only receive push notifications during the following state:

Notifications will ONLY be sent if all your clients are disconnected, or marked as away. You can use the clientaway module to mark a connected client as away. (https://github.com/cocodelabs/znc-palaver#when-will-i-get-notifications)

The background/foreground commands of the protocol mark the ZNC connection as "away". You can get similiar behaviour in non-Palaver clients by utilising features such as auto-away and using a module like znc clientaway. The intention is that you do not receive notifications on other devices while you have an open Palaver instance in the foreground. I.e, when I am actively using IRC on one device the other devices and clients shouldn't be receiving notifications and making sounds.

While znc-palaver should not send push notification to the connected client regardless of being in the background (because it already receives the message over the TCP socket - the notification would be local and not remotely triggered). It is used to send notifications to other registered devices to the ZNC network, such as if you have more Palaver devices (iPhone, mac, iPad etc). When one device (such as the iPhone application) is backgrounded, it will allow mac and iPad to receive notifications.

Similiary, when a device comes back to the foreground it allows ZNC to "reset" the unread state for other clients. I am not 100% sure if that behaviour is implemented in the znc module as specified, but it is the intention (https://github.com/cocodelabs/znc-palaver/blob/cb74b8f119a548dbe9b59de638db65c7bcf2d8a7/palaver.cpp#L764).

This may be server implementation specific on what it does with this information. It could be that other server implementation can use this information. One example is "auto away" functionality, there is a clientaway module for ZNC which sets the upstream IRC server away state if desired when all devices are either disconnected, away, or in palaver terms backgrounded.

[kylef]

@slingamn I've been thinking about a more generic solution to this problem which may be a bit more flexible and count for any other client needs. This particular spec does not count for being able to reply to a notification, it would be desired in Palaver to be able to make a HTTP request to send a response. There could be a more generic way for clients to register web callbacks and sending IRC commands over HTTP which I've explored in https://gist.github.com/kylef/ad79980a6ebe2e23a2862cfedbd62f8b.

[slingamn]

Belatedly, @prawnsalad and @xPaw had thoughts about this, but they're better qualified to discuss them (I don't understand client issues that well).

[delthas]

Relates to: https://github.com/emersion/soju/blob/master/doc/ext/webpush.md