we should cache/track when users last spoke in a room for presence and idle-kicking etc (SPEC-197)

[matrixbot]

Submitted by @​matthew:matrix.org

(Imported from https://matrix.org/jira/browse/SPEC-197)

[rubo77]

Bump.

I think this is quite urgent

[ara4n]

per-room can always be calculated clientside; this is a nice-to-have surely. presence is good enough metric for kicking idlers.

[r4dh4l]

What is the current state of this idea? Is it planned to add a room settings option like "Automatically kick user who didn't say anything since X days"? I would highly appreciate an "anti-lurker mode" for rooms.

[NotAFile]

I really don't think kicking old users should be part of the spec. Such specialized functions can easily be handled by dedicated bots, or even client-side tools.

[r4dh4l]

Well, I don't think that auto-kicking lurkers is a "specialized function" from end user's perspective. "Lurking" is a common problem and it would be a really nice feature for groups to have a room setting to auto-kick lurkers without asking the homeserver admin for help.

Edit: Manually kicking users (by hand/scripts/bots) is always a little bit offensive. A setting saying "lurkers will be kicked after 30 days" which is transparent for all room members causes much less stress for room admins and moderators in my opinion.

[jcgruenhage]

Doing this without impersonating a mod/admin or a bot that is a mod/admin, so making it part of the spec, wouldn't be an easy thing to do and would require a change in the state resolution algorithm. I don't think that this should therefore be part of the spec. I'd like to have a bot which does this though, which is why I created turt2live/matrix-wishlist#214

[jcgruenhage]

How is an admin telling the bot to kick automatically after 30 days more offensive than the admin deciding that in the room settings?

[r4dh4l]

I'd like to have a bot which does this though, which is why I created turt2live/matrix-wishlist#214

Thx for the hint.

How is an admin telling the bot to kick automatically after 30 days more offensive than the admin deciding that in the room settings?

It is not as long as new members can easily understand the purpose of the bot and see the current settings. Given this I would agree that there is not much difference.

[jcgruenhage]

The bot could send the current settings on request and the admins could put the settings into the topic for visibility

[Half-Shot]

This honestly seems like an implementation feature, or perhaps an admin API but the issue is worded to sound like the spec should demand it.

For what it's worth, we do track user idle-ness in the IRC bridge at the moment anyway.

[jevolk]

I can't figure out how this is an issue for the specification. There are enough facilities in the existing specification for implementations to effect this. You're free to write a client bot or application service module or whatever you want which implements this feature.

The only advantage to adding something like this to the specification is that it forces everyone to add your feature. What if implementations don't cooperate? Will you invoke soft-failure mechanisms? Will you netsplit rooms over it? This feature relies on the institutional respect for the specification; respect for that is degraded when it's choc full of arbitrary impositions on implementations like this.

It's December, going on 2019 now. Matrix-doc has 501 open issues at the time of this writing. The august 2018 r0 spec is still woefully incomplete. This issue really ought to be closed for sane housekeeping and reopened if there's compelling technical and social arguments in its favor.

[Half-Shot]

Yes, I think this has been said by several people that kicking users on conditions is a task for bots and services but not a specification detail. I can see merit in an admin endpoint for fetching the last active times for users in a room according to that homeserver. This gives the bot/script/whatever more visibility about what they should be kicking.

This is how the IRC script currently works, in that we just fetch last active times from postgres and kick based on that. I assume any proposal to write such a feature would just define a metric for last active time and work off that.

[jevolk]

I can see merit in an admin endpoint for fetching the last active times for users in a room according to that homeserver ... I assume any proposal to write such a feature would just define a metric for last active time and work off that.

What about using a filter on the existing /messages endpoint which returns a limit=1 for a sender. If the spec were to improve anything accommodate this feature (and others like it) then that filter could be enriched with a limit_per_sender so an array of 1 message for each matching sender (i.e *) is the response.

[Half-Shot]

@jevolk That's actually quite a good idea. You could use that kind of filter for other purposes too, but it would definitely seem to fit this use case.

[jcgruenhage]

That would only be needed for a cleanup script run regularily, not something running constantly. If the bot is syncing anyway to respond to commands, it could keep track of the last message of a user in that room (or group of rooms) by itself. Especially if RRs count as activity then we need a full sync anyway.

[Half-Shot]

I can still think of other reasons to know the last message posted by each sender in the room, and to be honest the sync solution requires you to join each room you plan to clean up N days beforehand to actually start tracking, which is a bit inadequate.

[jcgruenhage]

You do realize that you already have a bot in all those rooms with the IRC bot, right? You could use that account and backfill N days.

[Half-Shot]

1. ghosts can't sync. 2) the performance of doing a sync often with that account would surely kill the home server :)

The performance of doing a few /messages calls whenever the script gets run will surely be better.

[jcgruenhage]

Is the appservice bot a ghost? Also, why can't ghosts sync?

[Half-Shot]

Is the appservice bot a ghost? Also, why can't ghosts sync?

https://matrix.org/docs/spec/application_service/r0.1.0.html#using-sync-and-events

[Half-Shot]

Two years later, we're using read receipts/typing/actual messages sent over the AS api to calculate the last time a user read or spoke in the room. I wonder if this issue needs to remain open now we have a fairly optimal way of tracking this.