I disagree here, and that seems to be at the core of our different approach to this issue. By default our libs shouldn't be logging with such a verbose setting, or if they do, leap.bitmask should not be the place to handle those logs to the main log file / stdout. ( Actually I think we should put a nullHandler on all the component libs by default, and we should be following an opt-in policy to logs with a configured handler, but let's leave that for another iteration.)

In my mind there is this case: when we receive logs from user, I don't want to skim through tons of redundant info to get the debug logs that are of interest to us at some point in the development cycle. Right now we're seeing the signal-event info at several points (events client, server, registered callbacks etc), but I think we safely can assume that the events component has been extensively tested and debugged till the point in which we do not want to pollute the client logs with too many details for each event (~15 lines for each event like we have now make everything difficult to track).

Setting --debug flag should enable DEBUG level logs for the bitmask project, but not for other components that are much more tested and are expected to be well-behaved, and this should be a default behavior. So, again, I think bitmask should configure a sane default of verbosity levels on the different components, so we have well covered a vanilla build in which we can ask a user to enable the debug flag and send those logs to us. Even when that "user" is a fellow developer that is trying to debug something with the client.