add pre-away extension

[slingamn]

This comes out of ircv3/ircv3-ideas#96 . It provides a mechanism to indicate that a new connection was not initiated by an end user and does not indicate that the end user is present. The core objective is to work with auto-away systems, but the mechanism is potentially more general.

[slingamn]

cc @emersion @causal-agent

[sadiepowell]

This seems like it just overcomplicates the problem. Why not use an unrequestable cap that tells clients they can send AWAY with a normal message before connection registration is complete like with sts?

Never mind, I think I understand what problem this is also trying to solve.

[progval]

@SadieCat This spec does that and defines AWAY * which tells the bouncer/server not to change the away status because of this connection

[emersion]

This looks good!

Implementations:

• soju: https://git.sr.ht/~emersion/soju/commit/9f3596824112b577f732137459df2612ef5978fe
• Goguma: https://git.sr.ht/~emersion/goguma/commit/127bc622e61f6ae1131fdf4fb8678898be2c9b08

[slingamn]

cc @kylef : can FOREGROUND / BACKGROUND be translated into AWAY and AWAY * under this specification?

[slingamn]

From implementing this in Ergo (ergochat/ergo#2044) and discussion with @emersion, two changes:

1. Negotiating the capability is now required; this gives server implementations more information, at negligible cost
2. Explicitly mention AWAY * post-registration (this is the intended flow for "backgrounding" a mobile app)

[kylef]

@slingamn its not quite the same thing. They have different semantics as BACKGROUND/FOREGROUND are (client -> bouncer) whereas AWAY/UNAWAY is (client -> bouncer -> server). BACKGROUND/FOREGROUND do not leak the away state of the client to other clients.

If that could be a privacy concern for a user I do not know. In Palaver "auto away" is not enabled by default. BACKGROUND/FOREGROUND will be sent for supporting servers regardless of the user's "auto away" preference as it is for managing notification state and not exposing an away state.

Slightly related, in ZNC (using the clientaway module), a per-client away state can be configured, where if all clients have decided to be away then the away can (optionally) be propagated to the upstream server (to be visible by other clients). I presume that is the desirable behaviour with the proposed specification and what we might see in Ergo utilising pre-away?

[kylef]

2. Explicitly mention AWAY * post-registration (this is the intended flow for "backgrounding" a mobile app)

With a mobile application, you may also be going away/unaway very frequently and may not want this to by directly visible to others IRC users when jumping back and fourth between applications. In this context if AWAY/UNAWAY is a proposed alternative to BACKGROUND/FOREGROUND, it may be desirable for server implementations to offer some form of "delay" so that if a client aways and unaways within 10 seconds for example, it is not the user's away state.

[slingamn]

Thanks, that makes sense. What information do BACKGROUND and FOREGROUND convey to to the bouncer? Or rather, how does the bouncer make use of that information?

[sadiepowell]

Can you clarify whether this means a client receiving it for themself or other users? If it's the latter then this gonna cause weird behaviours on servers that don't support the spec. Might be best to require servers to rewrite it to something sensible?

[slingamn]

If I changed it to say "Clients having negotiated the capability", would that alleviate concerns about behavior on servers not supporting the spec?

[slingamn]

I think the language is more clear now:

• If the capability is negotiated, * has a special meaning in both directions (albeit only at the SHOULD level)
• If the capability is not negotiated, the behavior is implementation-defined; servers may give * its special meaning regardless, or may implement the traditional meaning

[emersion]

Now shipped as a vendored soju ext: https://git.sr.ht/~emersion/soju/commit/c36bb342fb13604996214951bfec477abfa38843

Now replaced with the draft spec!

[delthas]

LGTM

[jesopo]

this functionality isn't super important to me, but it seems to be to others and i have no objections to it. lgtm

[emersion]

Thanks a lot!

[awfulcooking]

That USER bitmask in rfc2812, tho :)

[sadiepowell]

As a minor (dont let this block anything) bikeshed before this is ratified: given that AWAY * can be sent after registration might there be a more appropriate capability name for this than pre-away? e.g. generic-away, extended-away, etc.