Chatterino2: Add ability to trigger the recent-messages api without restarting the client.

[Mm2PL]

Is your feature request related to a problem? Please describe.

When the connection is dropped and Chatterino reconnects. There's no way to see what messages were sent between the disconnect and reconnect.

Describe the solution you'd like

I would like a menu option and/or a command that shows historical messages obtained using the recent-messages service using a popup similar to the search one.

Describe alternatives you've considered

• Not doing it at all
• Automatically filling in the messages that couldn't be received. If the API doesn't have a parameter in the request to select the time we want the messages from, there would be a need to filter them based on the timestamps.

Additional context


Currently there is no way to see the recent messages without using logs or restarting. Logs don't show every users' actions.

[Evanito]

How about automatically doing so when a reconnect is detected to fill the gap since the disconnect?
I don't know the limits of randers' log API but if an after-time can be specified, that would be 💯 👌 🔥

[Mm2PL]

That would be even cooler.
E: Edited issue to include your idea.

[RAnders00]

How about automatically doing so when a reconnect is detected to fill the gap since the disconnect?
I don't know the limits of randers' log API but if an after-time can be specified, that would be 💯 👌 🔥

My API does not support such a feature, but you can easily filter the returned messages by time range/start time yourself using the rm-received-ts tag present on all returned messages.

[RAnders00]

Duplicates #915, will close the older one and post the conversation here for completeness:

RAnders00 commented on 7 Jan
When reconnecting, there is a short pause where chatterino is not connected to IRC. Messages that are sent during this time are missed by chatterino. Maybe chatterino could keep the old connection alive (maybe for a maximum of 5-10 seconds) OR until the new one is connected and has received the first message? Or maybe consult the endpoint for getting the last messages in a chat like it does on the initial connect, and merge the chat messages with the existing ones.

TETYYS commented on 22 Jan
I think account connections should be kept alive for a minute or two of no usage, this would prevent rapid reconnections if user wants to switch between two accounts multiple times.

[RAnders00]

@Evanito There is no need for after-time on my API. Messages are strictly in order of time received, and you can use @rm-received-ts to filter messages based on time received.