search

ircv3 / ircv3-ideas

46 stars 3 forks source link

Add a way to mark user as away pre-registration #96

Closed emersion closed 10 months ago

emersion commented 2 years ago

Use cases:

Prior art: causal.agency/passive, see https://git.causal.agency/pounce/about/pounce.1#Extensions

If I had to spec something, I'd add an ext to allow clients to send AWAY before connection registration is complete.

jesopo commented 2 years ago

maybe pre-reg user metadata could have a generalised solution

slingamn commented 2 years ago

I support this idea.

If I had to spec something, I'd add an ext to allow clients to send AWAY before connection registration is complete.

This would overwrite the currently set away message, right? That seems undesirable, since the reattaching client may not have access to the "correct" away message.

I like the design of causal.agency/passive for this.

jobe1986 commented 2 years ago

I like the idea of being able to simply send AWAY pre-registration.

AS for the issue of it causing a change to away message for reattaching, perhaps the solution there is to provide a means for the server (be it IRCd or bouncer) to notify the reattaching client of the existing away message in a similar way to away-notify when the client has supplied a pre-reg away message, and then ignore the supplied message keeping the existing one, and then only updating it if the client sends another AWAY after registration.

emersion commented 2 years ago

This would overwrite the currently set away message, right? That seems undesirable, since the reattaching client may not have access to the "correct" away message.

It depends. If the server allows multiple clients to connect for the same user (e.g. ergo, or a bouncer), then the server cannot just use the latest AWAY command sent by the client to update the user away state. If I don't use my laptop for 1h, but am still active on my workstation, I don't want to be marked as away. So the server needs to aggregate the state from all clients, and use that to update the effective user AWAY status. If a single client is connected, the server may use that AWAY message. If multiple clients are connected, the AWAY message from a client should not override another client's.

All of this is assuming that clients send AWAY automatically when the user isn't active. Is this reasonable?

I like the design of causal.agency/passive for this.

causal.agency/passive has a drawback: once the client has enabled the cap, they can't switch back to unaway. The connection is permanently marked as away. This causes issues on mobile devices, where the away status needs to be cleared when the app is bring to foreground after a background synchronization.

slingamn commented 2 years ago

If a single client is connected, the server may use that AWAY message. If multiple clients are connected, the AWAY message from a client should not override another client's.

It's not clear to me that these are the correct semantics. It sounds like you're suggesting that the first-set away message should take precedence? That seems like it could result in it being difficult or impossible to change the away message (if you set it from a long-running client that you temporarily don't have direct access to).

Ergo (typically) does aggregation but the last-set message wins, not the first-set.

causal.agency/passive has a drawback: once the client has enabled the cap, they can't switch back to unaway.

We could add a C2S command to cover this, right? PASSIVE OFF or something?

emersion commented 2 years ago

It sounds like you're suggesting that the first-set away message should take precedence?

No, I'm trying to say that once multiple clients are involved, there's no reliable way for the server to pick the "correct" AWAY message. Maybe the long-running process has bad connectivity and reconnects. Maybe the long-running process is in a cron job and periodically connects/disconnects (much like goguma). In these cases last-set doesn't work well.

It would be nice to allow clients to make the difference between "AWAY message is explicitly set by the user" and "AWAY message is default/auto". A bit like realnames. Maybe an empty AWAY message (not sure they're widely supported?) or a special string?

We could add a C2S command to cover this, right? PASSIVE OFF or something?

This sounds like re-inventing AWAY again.

slingamn commented 2 years ago

This sounds like re-inventing AWAY again.

Well, it wouldn't alter the away message. That's the point.

slingamn commented 2 years ago

Maybe I'm missing something but I don't understand what is gained here by using AWAY for this, when:

  1. The goal is at best peripheral to the traditional functionality of AWAY
  2. There is no savings in spec complexity (clients still have to read an informational CAP to be able to send AWAY or PASSIVE pre-registration)
  3. Using AWAY immediately entangles this spec with the unclear semantics of multi-client AWAY (I agree with your argument that there is no one right answer there --- but that seems like a great argument for not using AWAY)
emersion commented 2 years ago

The goal is at best peripheral to the traditional functionality of AWAY

My goal is exactly the same as AWAY.

There is no savings in spec complexity

Clients need to learn about a new command which does the same thing but not exactly. PASSIVE would result in AWAY messages broadcast to other users. What if a client uses both PASSIVE and AWAY? Which one wins?

Using AWAY immediately entangles this spec with the unclear semantics of multi-client AWAY (I agree with your argument that there is no one right answer there --- but that seems like a great argument for not using AWAY)

That's fine -- the client doesn't need to know about what the server decides. The client only needs to report enough information for the server to make the correct decision.

slingamn commented 2 years ago

PASSIVE would result in AWAY messages broadcast to other users.

There's some ambiguity here between the AWAY command (which conveys both away-ness and un-away-ness) and "away message" (the human-readable string conveying why the user is away). The semantics I'm imagining for PASSIVE is that it never sets or broadcasts a new away message:

  1. PASSIVE ON, pre-registration, cannot change the publicly visible away state. If the client was considered away before, it's still away; if it was considered un-away before, it's still un-away.
  2. PASSIVE OFF may result in the client becoming un-away, hence clearing the publicly away state; so this does broadcast an AWAY command, but not an away message.

If this is specified using AWAY it seems like there are two possibilities:

  1. Send a normal AWAY command with an argument pre-registration; in this case, there is the risk of that away message being broadcast to end users.
  2. Special-case the empty AWAY message, or a special string of some kind, for this purpose: this seems like reinventing PASSIVE (but in a less explicit way).

What if a client uses both PASSIVE and AWAY? Which one wins?

When would there be a conflict here? (But also, if it's out of scope to specify "who wins" in the context of multi-client away, it seems like we shouldn't specify this either. I have a picture in my mind of how PASSIVE and AWAY should interact --- with PASSIVE enabled, the client session is simply "not counted" for presence purposes, and any explicit AWAY message that was sent is temporarily ignored --- but it doesn't seem like something we would write into the spec.)

emersion commented 2 years ago

PASSIVE ON, pre-registration, cannot change the publicly visible away state

What if a client sends PASSIVE ON post-registration? This would switch the state from un-away to away.

When would there be a conflict here?

So the user is counted as away if either PASSIVE ON or the AWAY message is set?

slingamn commented 2 years ago

What if a client sends PASSIVE ON post-registration? This would switch the state from un-away to away.

This should probably be rejected or disallowed:

  1. If the client doesn't want to maintain the connection, they should just QUIT
  2. If the user is no longer "at keyboard" but the client intends to maintain the connection, the correct command is AWAY (but this workflow is peripheral/deprecated for the use cases we're interested in; passive connections are primarily relevant in contexts where the server supports history and persistent presence).

So the user is counted as away if either PASSIVE ON or the AWAY message is set?

More or less (modulo questions about multi-client aggregation). If they went through connection registration with PASSIVE ON, it's as if that connection didn't exist at all.

emersion commented 2 years ago

What if a client sends PASSIVE ON post-registration? This would switch the state from un-away to away.

This should probably be rejected or disallowed

That doesn't work for mobile:

slingamn commented 1 year ago

It seems sound, in theory, to allow PASSIVE ON post-registration and treat it as equivalent to QUIT for presence purposes. So it would be capable of changing the publicly visible away state, but only in ways that already exist.

This has gotten very complicated. Proposed quick and dirty alternative: an informational CAP that allows AWAY pre-registration, but recommends that clients and servers SHOULD treat AWAY * as meaning "the user is not present, for unknown reasons". (This seems relatively backwards compatible. The worst case is that some legacy client ends up displaying * to a human as the away message --- we've all seen worse.)

emersion commented 1 year ago

Sounds good to me. Any reason why the cap only recommends * to be treated as "no reason", instead of requiring it?

emersion commented 1 year ago

Ah, I suppose the issue is with clients which receive the AWAY * broadcast, not with servers.

slingamn commented 1 year ago

I think MUSTs associated with AWAY * would pose backwards compatibility issues, since this form exists and already has semantics under RFC1459. SHOULD seems like the right balance...

emersion commented 10 months ago

draft/pre-away has been merged.