I noticed that the default network flood rates are wrong (for most
networks). It has been very standard since the beginning of IRC to use a
value of 2 seconds per line, with a 10 line head start. Almost all
networks work this way, and if you don't follow, having a lot of
channels or a lot of clients connected to ZNC results in excess flood
disconnections and much frustration for the user.
I think you should make the default value for these 2 and 9 instead of 1
and 4 so that this nasty bug doesn't hit people who will not know how to
debug it. You find these same types of settings built into every IRC
client. 2 and 10 is the standard. 2 and 9 provides a slight buffer so
there is no mistake.
Thanks
-Rubin
Close#1416
Added the following two network-specific configuration options that can
be changed via controlpanel or webadmin:
* TrustAllCerts: Will trust ALL certificates when enabled, effectively
disabling TLS certificate validation.
Default value: false
* TrustPKI: Whether or not to trust PKI-valid certificates. Setting this
to false will make znc trust only trusted certificates added by the
user.
Default value: true
With default values, behavior is exactly the same as before.
This is based on the work of Roelf Wichertjes. See YourBNC/znc@5c747598.
See znc/znc#866.
This updates the connect command in *status to retrieve the next server
object before triggering the jump, thereby allowing it to display the
next server's name rather than a generic message.
This change alone doesn’t notify any capabilities to clients, but makes
ZNC itself offer cap-notify and builds the foundations for various
notifiable capabilities, such as away-notify, can be easily added.
This reverts commits 27d78795a7 and
f27109f1b4. It was decided that the
functionality is provided by a separate module instead, to avoid
unnecessarily bloating the core.
Originally removed when query buffers were introduced in 14a534c.
The ideal name would be plural ClearQueryBuffers() now that there
are multiple query buffers, but use the old name for compatibility
reasons (see https://github.com/kylef/znc-contrib/pull/18).
To let modules know whether a client is currently in playback mode.
The clientbuffer module (#343) wants to update "last seen message"
timestamps in OnSendToClient() but it must avoid doing that while
in playback mode.
This allows implementing timestamp-based (eg. client specific - #343)
filtering of playback buffers. For clients that don't support server-time,
getting an accurate timestamp out of a raw buffer playline is impossible.
FindClient() is not enough, because there are no restrictions to used
identifiers. They don't necessarily need to be unique, and the same
identified client might re-connect meanwhile a ghost connection is
still hanging there.
The old AttachUser() that sent JOIN without topic or names replies
would leave clients in incomplete/broken state. JoinUser() was doing
two things; depending on passed arguments it was either joining user
on the channel on IRC, or attaching clients (properly). Now JoinUser()
joins the user on IRC, and AttachUser() attaches as expected from the
method names.
