Private mode without persistent connections

[jprjr]

Hi there -

I'm using The Lounge as a client for ZNC.

Since ZNC is already handling maintaining my IRC connections while my client is disconnected, I was trying to find some option to enable private mode (to save users with their preferred networks etc) but turn off the multi-client/stay connected feature.

Thank you so much!

[maxpoulin64]

Hmm, I'm not sure of the usefulness of doing that. One could just leave them connected, it's not like it will hurt anything. I do run ZNC as well, but it's more convenient to just leave Lounge running as well. That way it loads instantly. Reconnecting Lounge is a little bit more annoying than leaving it on, since you have to wait for the network to connect and then get a load of notifications as the buffer plays back.

If you don't want it taking memory, you can disable history saving entirely by setting limitHistory: 0. Then you only have the overhead of the Lounge<>ZNC connection, which is quite negligible compared to running to running in public mode.

[jprjr]

I just did some experiments with setting the history size to zero, and I think there's a small issue - AFAICT ZNC doesn't seem to save a playback buffer if clients are connected. So If I login with the lounge, close my browser, wait for some time, and log back in - I've got lost messages.

If Lounge was my only IRC client this wouldn't be a problem (I could use it's built-in history/persistent connection), but I use a couple of IRC clients across different devices, so having ZNC handle the persistent login/playback is preferred for my use-case.

[AlMcKinlay]

AFAICT ZNC doesn't seem to save a playback buffer if clients are connected

FWIW, that's a setting on znc. I'm not sure exactly which setting, but they
have a lot of settings about what should be in the playback and when.

On Wed, 20 Jul 2016 at 15:22 John Regan notifications@github.com wrote:

I just did some experiments with setting the history size to zero, and I
think there's a small issue - AFAICT ZNC doesn't seem to save a playback
buffer if clients are connected. So If I login with the lounge, close my
browser, wait for some time, and log back in - I've got lost messages.

If Lounge was my only IRC client this wouldn't be a problem, but I use a
couple of IRC clients across different devices, so having ZNC handle the
persistent login/playback is preferred for my use-case.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#519 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACD_4XjPUPHwRUup-QHxZXGu3R6nxTkeks5qXi8TgaJpZM4JQIuv
.

[jprjr]

@YaManicKill Found it - it's AutoClearChanBuffer and AutoClearQueryBuffer. Setting them to 'false' makes ZNC store messages in the buffer regardless of clients being connected.

This works pretty well, only downside is I'll get repeated buffer messages when I join but that's not too big of a deal.

I just tried searching the docs, does Lounge offer some kind of auto-away functionality? I thought I saw something, but I might be getting it mixed up with ZNC's auto-away. This is the one remaining downside (for me) of Lounge keeping the connection with ZNC open.

[AlMcKinlay]

only downside is I'll get repeated buffer messages when I join but that's not too big of a deal.

Yeah, at least you have a solution just now. Thoughts, @thelounge/maintainers, is this something we should look into, or you not bothered? I'm not sure there's enough usecase for it, tbh.

does Lounge offer some kind of auto-away functionality

No, but there is a ticket for it. #107 It is something that would be not too difficult to do, but we are going to be quite quiet over the next month or 2 due to the summer.

[dgw]

@jprjr Look into the clearbufferonmsg module for znc to remedy the issue of duplicated playback.

[maxpoulin64]

does Lounge offer some kind of auto-away functionality
No, but there is a ticket for it. #107 It is something that would be not too difficult to do, but we are going to be quite quiet over the next month or 2 due to the summer.

Actually there's also a patch for it, but I wanted to finish with #275 before I did that since it needs to be handled on the server.

When we have proper plugins, a ZNC plugin is definitely something I'll want to look into. Like, actually integrate The Lounge with ZNC by automatically picking up its networks and user accounts, and automatically handle its initial burst properly (or not mark it as a standard client, one or the other). But we might also go full bouncer instead, whichever happens first I guess.

EDIT: Marking as enhancement anyway, as some people also could not want the always-on feature and just want to use it as a nice web client. Or maybe like, disconnect after 10 minutes of inactivity.

[ftischhauser]

I would love to see the auto-disconnect feature! I'm using a multi-client ZNC setup with a push plugin that notifies me when no clients are connected. I currently have to manually start and quit lounge (or set the plugin to push all messages even when I'm active), so that would help a lot.

[dgw]

@ftischhauser If you're using jreese/znc-push then have a look at the client_count_less_than setting. I have a screenshot of my settings that I can edit into this comment when I'm back at a computer, which should help you configure your push notifications to work satisfactorily (assuming you use the plugin in question).

I would very much support a ZNC integration plugin for The Lounge once the API is implemented. Not so hot on The Lounge becoming a bouncer all its own, but that could conceivably be a different plugin.

[ftischhauser]

@dgw That's the setting I'm using for my traditional clients, but as the lounge is always connected it can't be used as an indication whether or not I actually have a browser window open.

[dgw]

@ftischhauser Not suitable to assume that The Lounge will be connected and set client_count_less_than 2 so if you are not connected on any other client, you will get notifications? In combination with the idle & last_active settings, you should be able to avoid getting pushes when you're actively chatting in The Lounge but still minimize the chance of missing a highlight while afk.

For reference, I'm quite happy with:

16:35   *push   +------------------------+--------------------------------+
16:35   *push   | idle                   | 300                            |
16:35   *push   +------------------------+--------------------------------+
16:35   *push   | last_active            | 180                            |
16:35   *push   +------------------------+--------------------------------+

Apologies for the long wait on this. It's been an excruciatingly busy weekend in the offline world for me.

[ftischhauser]

@dgw I prefer that the push messages start the second I quit the application on my active device and not only after a specific amount of time after my last action (otherwise I risk missing notifications). This works perfectly when I'm only using client_count_less_than 1 and the client disconnects from ZNC when I close it, but obviously not if the client is only a browser connected to the lounge. It's not a huge problem for me, but I'm just trying to say that an auto-disconnect feature would indeed be helpful in some scenarios :)

[dgw]

@ftischhauser Yep, and I'm trying to get you as close as possible to the ideal until such time as auto-disconnect or a ZNC module for The Lounge can make life perfect. :)

[maxpoulin64]

Maybe the autoaway could be of use here? Does that ZNC module support being configured to ignore clients marked as away?

[dgw]

znc-push does support an away_only condition that sends notifications only if the /away status is set. Combining that plus the channel_conditions & query_conditions settings with the auto-away patch could prove useful.

[ftischhauser]

@maxpoulin64 yes that could indeed be used as a real indicator, but compared to an auto-disconnect feature it doesn't solve the buffer playback issue as described by @jprjr - so that would still be preferable.

[astorije]

@maxpoulin64, it seems unlikely to me that we would implement the feature as described in original post. Should we close this issue?

[astorije]

Discussing with @maxpoulin64, we'll close this for now. This kinda goes against the spirit of the project, having an always-on client. Unlikely that one of the core maintainers will be implementing that, so if someone wants to open a PR for it, feel free to.