This adds a new ISUPPORT token, NICKLEN_USABLE which is strictly an informative value.
NICKLEN is always the maximum runtime NICKLEN supported by the IRCd, as other servers may
have their own usable NICKLEN settings. As NICKLEN_USABLE is strictly informative, and
NICKLEN is always the maximum possible NICKLEN, any clients which depend on NICKLEN for
memory preallocation will be unaffected by runtime changes to NICKLEN_USABLE.
The default NICKLEN is 50; the default serverinfo::nicklen in the config file is set to
30, which is the NICKLEN presently used on StaticBox.
nenolod gave the thumbs-up to port ircd-seven banfowards to charybdis to spb
for a while, and people have asked about it. Might as well do it since it's a
slow weekend.
Note that as a side effect use_forward is removed from the config and
unconditionally enabled!
While what chanroles are trying to accomplish is a good idea, it is
apparently unclear this is the proper way to do it. Until we figure out
the exact way we wish to do this, it should be reverted for now.
The theory behind this is that services sends an ENCAP * GRANT #channel
UID :+flagspec message specifying the chanroles the user has. They are
mapped into flag bits and applied to the membership of the user. They
then are restricted or permitted to what they can do based on the
permissions mask regardless of rank.
For backwards compatibility, the default permission bit (without a GRANT
statement) allows a user to to anything an existing op can do ONLY if
they are an op.
Todo: make CHANROLE_STATUS work (the ability to apply +ov to people),
which is at the moment controlled by CHANROLE_MODE.
Do kick_on_split_riding if services sends an SJOIN
with a lower TS and a different key. This relies on
services restoring TS (changets option in atheme) and
services not immediately parting after receiving the
KICK, which is the case in recent atheme.
For invite-only channels, still only do
kick_on_split_riding in netbursts. Services is
assumed to handle this itself (atheme does).
The reason why we do this is because some clients are dependent on receiving a numeric
for every channel join failure, even due to this limit where it can be assumed that
subsequent joins failed.
This has a separate enabling option channel::channel_target_change.
It applies to PRIVMSG, NOTICE and TOPIC by unvoiced unopped non-opers.
The same slots are used for channels and users.
* does not apply to NOTICE (as those may well be automated)
* mirrors +g behaviour so that no useless accept entries are added for services
* respects max_accept, if it would be exceeded the message is dropped with numeric 494
* check moved up so this is checked before floodcount/tgchange
This shouldn't provide any way for a client to get on a CALLERID list
without authorization, as if a client is +g already, a CTCP request, for
example, won't be replied to.
Special modes like +j can be tracked easily just by adding the necessary
code to parse them to set_channel_mlock(). This will cover propagation
as well.
Such bans are not applied locally, but are propagated normally.
They can only be removed on a server that applies them.
Note that normally KLINE will not accept such bans.
This is mainly for services, differing min_wildcard and
ircd changes.
A KLINE command without the ON clause now sets a propagated
("global") ban. KLINE commands with the ON clause work as
before.
Propagated klines can only be removed with an UNKLINE command
without the ON clause, and this removes them everywhere.
In fact, they remain in a deactivated state until the latest
expiry ever used for the mask has passed.
Propagated klines are part of the netburst using a new BAN
message and capab. If such a burst has an effect, both the
server name and the original oper are shown in the server
notice.
No checks whatsoever are done on bursted klines at this time.
The system should be extended to XLINE and RESV later.
There is currently no way to list propagated klines,
but TESTLINE works normally.
When a user receives a private message, notice or RPL_UMODEGMSG,
add the source to a special set of 5 target slots.
These slots are checked in the normal way when sending messages,
allowing a reply without using up a free target.
This feature will not be very useful if a user is being messaged
by many different users; to help this, messages blocked entirely
by +g or +R do not affect the targets. CTCP replies also remain
free in terms of targets.
