Part/leave rooms after archive is not checked for a while

[Mikaela]

In my opinion the @archive:matrix.org bot shouldn't stay in rooms it joins for all eternity like is it's current behaviour.

If not for other reason, to avoid Denial of Service towards matrix-appservice-irc users when encountering IRC side limits and thus triggering privacy filter. matrix-org/matrix-appservice-irc#1474 (comment)

[MadLittleMods]

The Matrix Public Archive is stateless (it keeps track of nothing between requests) which means there is nothing keeping track when a room was last accessed or when we even joined in the first place.

And the Matrix API's don't make it easy to retrieve this kind of information either. The only way to get a list of joined rooms is to use initial /sync which will not even respond in time once the Archive has joined a bunch of rooms.

And the only sort of last access time information available would be from a read receipt but those are EDU's (ephemeral data units) which are fire and forget and we can't get that information back out of server.

I can't think of a way to accomplish a periodic idle and leave check in a stateless world. Perhaps there is another angle to attack the IRC problem from though.

[Mikaela]

Would checking for matrix-org/matrix-spec-proposals#2346 help? The IRC bridge in question implements it

[MadLittleMods]

@Mikaela MSC2346 doesn't help in this scenario but generally, adding state to the room to track last access time would require the proper power levels for the archive bot user which is unnecessary permissions outside of this use case, a hassle for people to manage, and won't be given in most cases. It's also just noise in the room to have the state event change every time someone accesses the archive.

And doesn't solve the problem with the join limit for the IRC bridge since the archive could still join 250 rooms within the leave idle window. No matter what tuning is done, there is still going to be an edge case with this kind of solution.

[Mikaela]

To be explicit about #263, this affects every IRC network, particularly those using matrix-appservice-irc as I think every network contains a CHANLIMIT in their ISUPPORT.

• List of matrix-appservice-irc bridged networks

[Mikaela]

@Half-Shot confirmed this issue at #47 (comment)