Feature request: conversation & event logging.

[crabdancing]

I have started using Syncplay for study sessions with my friend. As we study, we chat back and forth and occasionally come to insights over the chat interface, which are useful to record for future grepping.

Unfortunately, the only way for us to save them currently is by hand. Would it be possible to add an optional dead-simple logging feature? I'm thinking something to the effect of storing logs as plaintext files under the existing ~/.config/Syncplay/logs, or ~/.local/share/Syncplay/logs if y'all prefer to put it in a more conventional place. The logs could simply be files created on a per-session basis, a la Pidgin (for instance, 2018-08-22.145910-0400EDT.txt for a session created at that time, then following that a new file uniquely based on the time of the next session, etc etc.)...

Or they could all be dumped to one continuously updated text file, if one doesn't mind the risk of forming very large files.

[crabdancing]

Oh, yeah, and Windows exists too. I forgot Windows exists. I suppose it could be put under %appdata% or something for the Windows people. :P

What does everyone think?

[Et0h]

Yes it would be possible. I'd be interested in hearing what people think with respect to:

• How it should be enabled/disabled
• What would be included in the log
• What a log should look like (i.e. provide an indicative example)
• What the filenames should look like - would it be linked to the room, file, date, server, etc?

[0lhi]

Inside /home/user/.config/Syncplay, create a logfile for every room that's named "Roomname.txt". This file should be structured like this:

#2021-08-12

[20:57:48] Syncplay is up to date
[20:57:48] Attempting to connect to syncplay.pl:8995
[20:57:49] Attempting secure connection
[20:57:49] Successfully reached syncplay.pl (151.80.32.178)
[20:57:49] Secure connection established (TLSv1.3)

Hello Olhi,

The Syncplay latest is available from http://syncplay.pl/


[20:57:49] Successfully connected to server
[21:01:50] Olhi is playing 'Episode.mkv' (23:37) in room: 'Roomname'
[21:02:35] User has joined the room: 'Roomname'
[21:04:13] <Olhi> Hello =)
[21:04:40] <User> Hii :)

#2021-08-14

...

The Chatlog should be enabled on Syncplay Configuration -> Messages -> Enable Chatlog.

On the Syncplay configuration, there could be a Log Icon next to the "Edit Room List" button that would open the txt of the currently selected room inside the standard txt Editor. Another option would be when connected to a Server: Window -> Show Chatlog (greyed out when there is no textfile).

[crabdancing]

Enabling/disabling should be done in server config as with any other feature. Logging should range from sparse to verbose, optimally.

For instance, in my use case, I'd just want a plaintext log of who said what. In the case of someone running a large server and troubleshooting a problem, they might want a log to tell them in detail what handshake happened and what JSON strings changed hands during the error.

In the case of someone running a private server that was subject to a hacking attempt, they might like to have a log that they can point fail2ban at so that they can automatically blacklist the IP. Or they might just detect it manually.

Ideally, all these use cases should be satisfied by the same code, so as to minimize the need for future refactoring. Logging should be minimal by default, to protect privacy -- perhaps with logging connections and disconnections like IRC servers typically do by default, but not logging everything that was said.

Since we live in the SystemD era, logging to STDERR is going to be fine for a lot of people, including me -- but some people might like logging to files to be a feature.

Since there are a lot of events to log, and I also wanted to create some sort of event hook system, I think an optimal way to handle these two things would be with a single function -- something like:

report_event("Sentence to help contextualize what's going on in log entry", contextual_data, log_level)

Which would simultaneously go on to log the event and optimally trigger external code for custom user scripts. Furthermore, log_level would just be a simple int with associated codes ranging from DEBUG (show everything) to NONE.

Hopefully server administrators should know their way around grep and the like, so logging different events to different files seems like overkill to me. I would just put it all in one file -- the location of which can be decided by the end user, but I imagine a lot of people (including myself) would just do something like --log-destination - to log to STDERR, and then just run the thing under systemd. To accommodate that, printing out dates on each log entry should be an optional feature. To keep things simple, STDERR logging should probably be default, with the option to override the target file object to an actual physical file of the user's choice.

I am aware that this would add quite a lot of additional configuration options... but on a side note I've been thinking about making a pull request to add a server configuration file -- so maybe I should take care of that first? Here are some config options we'll probably need:

• --log-destination: where to put the log file. Defaults to - for STDERR.
• --log-level: int value or associated keyword indicating how much to log. Set to 0 to disable logging entirely.

So... let me know what everyone thinks, and if any more input on my part is needed! :)

[Uriziel]

I think logging feature is cool for client side.

For the servers though, I guess it would go against Syncplay's: "no user data stored" policy.
In my opinion servers should still avoid the logging feature altogether. Also it would add uncanny amount amount of work.

For the clients, I think logging what's appearing in the GUI should be enough, can't see any reasons for log-levels.
For the destination, if it's not a single file log, then Syncplay would need to create a folder for itself to store all the files (in home/%appdata%).

Cheers.

[Et0h]

Given the lack of any comments since March 2019 there does not appear to be significant demand for this feature. If someone made a pull request along the lines suggested by @Uriziel then it would be given serious consideration, but generally we don't want to add to the complexity of the UI or to significantly increase of the codebase.