The new configuration variable "Network" is used to set the (completely
optional) "network name", to which this instance of the daemon belongs.
When set, this name is used in the ISUPPORT(005) numeric which is sent to
all clients connecting to the server after logging in.
Closes bug #165.
This patch introduces the new numeric 310(RPL_WHOISSERVICE) and enables
WHOIS to display information about IRC services. This numeric is used
for this purpose by InspIRCd, for example -- but as usual, other numerics
are in use, too, like 613 in UltimateIRCd ...
Please note that neither the Operator (+o) not the "bot status" (+B)
of an IRC service id displayed in the output.
Change suggested by Federico G. Schwindt <fgsch@lodoss.net>, Thanks.
Replaced error message for channel mode +M with ERR_NEEDREGGEDNICK_MSG
(used by Bahamut, inspircd, ircu & Unreal too) and using numeric 477
and the msg simliar like inspircd.
Replaced the error message ERR_CANNOTSENDTONICK_MSG for user mode +b
with ERR_NONONREG_MSG and using numeric 486, similar like unrealircd.
(cherry picked from commit 55a61ab17f63a9e757b7c7598c31b98ce5a132e8
and commit 3737d9ab7da1ea0485cefc07c65dc5308bf0db02)
When a user has set mode "b", all private messages and notices to this
user are blocked if they don't originate from a registered user, an IRC Op,
server or service. The originator gets an error numeric sent back in this
case, ERR_CANNOTSENDTONICK_MSG(976), which is/was(?) used by KineIRCd, too.
This closes bug #144.
This error message is not only used if one can not send to a channel
because it is moderated, but for _all_ reasons when a message can not
be delivered (moderated, banned, no external messages, ...), so strip
the "(+m) -- Moderated" part of the error message again.
Bug introduced by commit 9a82304a.
Implement numeric RPL_WHOISMODES_MSG(379) and show user modes in the
reply of the WHOIS command for the user himself or, if MorePrivacy
isn't set, for request initiated by an IRC operator.
Numeric 379 is used by Unreal and InspIRCd for this purpose, too.
Closes bug #129.
If the new channel mode "V" is set, the INVITE command becomes invalid
and all clients get the new ERR_NOINVITE_MSG(518) reply.
Unreal and InspIRCd uses this mode, too.
This closes bug #143.
This closes bug #109.
* bug109-CHARCONV:
Debian: require "telnet" or "telnet-ssl" for building
Debian ngircd-full[-dbg]: enable CHARCONV
Add "CHARCONV" to "feature string" when enabled
Implement new IRC+ "CHARCONV" command
Added new configure option "--with-iconv"
Conflicts:
src/ngircd/messages.h
Both modes protect users from channel kicks: only IRC operators and
servers can kick users having mode "q" or in channels with mode "Q".
Original patch by DNS777 <dns@rbose.org>, thanks!
This closes bug #141.
* 'xop' of https://github.com/kart0ffelsack/ngircd:
Tests and documentation for xop
Implemented xop support
Conflicts (because of merge of the 'cmode-M' branch):
src/ngircd/channel.c
src/ngircd/defines.h
src/ngircd/messages.h
This numeric is sent to the client each time it changes its displayed
hostname using "MODE +/-x", and if "CloakHost" is set right after the
MOTD has been sent.
This patch series allows ngIRCd to support the user mode "B" ("Bot flasg"):
it is settable and unsettable by every (non-restricted) client.
According to DNS777, this is how Unreal and InspIRCd do behave, so do we :-)
By Alexander Barton (1) and DNS777 (1)
* umode-B:
Add new user mode "B" to doc/Modes.txt
Implement an Unreal-like user mode "B" ("Bot mode")
By Alexander Barton (2) and DNS777 (1)
* cmode-M:
Add new channel mode "M" to doc/Modes.txt
Remove Can_Send_To_Channel_Identified()
Implement channel mode "M"
This patch introduces the new function Conf_NickIsBlocked() which checks
if a given nick name matches with the "service mask" of a configured server.
And Client_CheckNick() uses this information to deny such names for regular
IRC users.
So nick names intended for IRC services are more protected and can't be used
by regular users even when the "services pseudo-server" isn't connected to
the network.
But please note:
Up to now, there can be only one "ServiceMask" pattern per server, which
most probably blocks much more nick names than really required ...
So "ServiceMask" should allow more than one pattern which can be more
specific, and most probably it should be possible to block nick names in
the global server configuration as well.
Nick names introduced by other servers/services are never restricted.
3 new channel user modes have been added.
Half Op: +h(Prefix: %) can set the channel modes +imntvIbek
and kick all +v and normal users.
Admin: +a(Prefix: &) can set channel modes +imntvIbekoRsz and kick all
+o, +h, +v and normal users.
Owner: +q(Prefix: ~) can set channel modes +imntvIbekoRsz and kick all
+a, +o, +h, +v and normal users
This patch implements the core functions to support "IRC Capabilities"
and the IRC "CAP" command as used by other servers and specified here:
<http://www.leeh.co.uk/draft-mitchell-irc-capabilities-02.html>.
It enables ngIRCd to support the defined handshake, but it doesn't
implement any capabilities, so "CAP LS" and "CAP LIST" always return
the empty set and "CAP REQ ..." always fails with "CAP NAK".
The numeric RPL_WHOISHOST_MSG(378) returns the DNS hostname (if
available) and the IP address of a client in the WHOIS reply.
Only the user itself and local IRC operators get this numeric.
This allows a channel operator to define exception masks that allow users
to join the channel even when a "ban" would match and prevent them from
joining: the exception list (e) overrides the ban list (b).
If the target user of a PRIVMSG or NOTICE command has the user mode 'C'
set, it is required that both sender and receiver are on the same channel.
This prevents private flooding by completely unknown clients.
- User mode "R": indicates that the nick name of this user is "registered".
This mode isn't handled by ngIRCd itself, but must be set and unset by
IRC services like Anope.
- Channel mode "R": only registered users (having the user mode "R" set)
are allowed to join this channel.
"I've been wanting this for years and finally took the 5 minutes to
patch it in. I took the response code (275) from whatever's running
OFTC's IRC network."
-- Neale Pickett <neale@woozle.org>, Fri, 11 Jun 2010 17:32:41 -0500
(OFTC is running Hybrid ircd.)
The RPL_STATSCONN numeric (250) displays information about the
highest simoultaneous connection count and the number of all
accepted connections since the daemon started up.
Used by ircd-Hybrid, Bahamut, and Unreal for example.
Only clients using a SSL encrypted connection to the server are
allowed to join such a channel.
But please note three things:
a) already joined clients are not checked when setting this mode,
b) IRC operators are always allowed to join every channel, and
c) remote clients using a server not supporting this mode are not
checked either and therefore always allowed to join.