Because msgstore_fs writes logs in localtime, the CHATHISTORY timestamps
(UTC) must be converted to localtime prior to filtering ranges ensure
the right range is sent back to the client.
Prior to this patch, the iteration back from the BEFORE time failed to
load the hours between midnight UTC and midnight localtime in each day's
logged messages. This is because the final time to be considered in a
day's log file (the "start" time) reuses the previous start time's
locale:
start = time.Date(year, month, day, 0, 0, 0, 0, start.Location()).Add(-1)
By converting the original start and end from the CHATHISTORY commands
to localtime in Load*Time and ListTargets, we ensure we read through
midnight each day.
go-proxyproto added support for a read timeout in 0.6.0[1] and
defaulted it to 200ms. After this time if no data is read on
the socket, it is closed.
This is _really_ low if the underlying connection is a TLS
one as no data pops out the other end until the handshake is
done. It effectively limits you to TLS connections within
a 50ms RTT of your bouncer with clients that are fast enough
at responding.
It appears that HexChat on Arch is somehow slow enough at
TLS connections thant it consistently takes longer than
200ms even over localhost, meaning it outright can't connect
to soju any longer.
To make this a lot less painful, have soju pass in a read
timeout of 5 seconds. This feels like a reasonable tradeoff
between keeping (possibly malicious) connections open and
accepting the realities of network connections.
[1]: https://github.com/pires/go-proxyproto/issues/65
See https://ircv3.net/specs/extensions/capability-negotiation
> Upon receiving either a CAP LS or CAP REQ command during connection
> registration, the server MUST not complete registration until the
> client sends a CAP END command to indicate that capability negotiation
> has ended.
This commit should prevent soju from trying to authenticate the user
prior to having received AUTHENTICATE messages, when the client eagerly
requests capabilities with CAP REQ seeing available capabilities
beforehand with CAP LS.
Since NULL = NULL is always FALSE, this query needs to use IS instead.
This should fix the flood of DeliveryReceipts in the DB.
See https://www.sqlite.org/lang_expr.html
> The IS and IS NOT operators work like = and != except when one or both
> of the operands are NULL. In this case, if both operands are NULL,
> then the IS operator evaluates to 1 (true) and the IS NOT operator
> evaluates to 0 (false). If one operand is NULL and the other is not,
> then the IS operator evaluates to 0 (false) and the IS NOT operator is
> 1 (true). It is not possible for an IS or IS NOT expression to
> evaluate to NULL.
