This will allow us to modularize message processing, e.g. having new modules to manipulate
channel and private messages in new ways.
Yes: it can be used to intercept messages, but such modules are already out in the wild for
charybdis anyway -- so this doesn't really change anything there.
If you are changing the text, then it is your responsibility to provide a pointer to a new
buffer. This buffer should be statically allocated and stored in your module's BSS segment.
We will not, and cannot, free your buffer in core, so dynamically allocated buffers will
cause a memory leak.
This will allow us to simplify m_message considerably, by moving channel mode logic out to
their own modules.
Arbitrarily prefer a forward channel to no forward channel and an
alphabetically higher forward channel to a lower one.
This is a simplistic implementation that generates one MODE message to
local clients for each ban removed (to be replaced).
For simplicity and to avoid amplification of incoming MODE messages,
regular modes may still desync the forward channel of a ban.
If a netburst adds bans or a channel TS change removes bans, +b/-b modes
are generated. Make sure these contain the forward channel, if any.
This appears also broken in ircd-seven.
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.
A large group is any $$ or $# or a channel with more than
floodcount/2 local members, checked on each server separately.
Note that floodcount checks are done on the sender's server.
The special treatment is active for 15 seconds.
to restrict channel names to printable ascii only.
Like disable_fake_channels this only applies to joins
by local users; unlike disable_fake_channels it applies
to opers as well.
This gives a useful meaning to the cmode combo +mz-n:
messages from ops and voices go to all channel members,
messages from anyone else (on or off channel) go to ops.
With +mnz, messages from outside are not allowed at all.
A juped server is defined as a server that already
exists with a service{} server as uplink.
If a juped server is introduced by another server,
this generates snotes/logs as before.
Local-only server notices kept here because
hub_mask/leaf_mask tends to be specific to a (hub)
server. The same information is now available in
Netsplit notices.
These come from the name field which is empty for unknown
connections attempting to become a server.
Instead, put [@255.255.255.255] just like ratbox3 does.
These are unreliable in general and only useful
for violating certain restrictions.
Sending such messages to remote servers is still
possible, for securely messaging pseudoservers whether
service{}'ed or not. The special oper-only syntax
opers@server remains as well.
This avoids annoying users when someone links a test
server with the wrong nicklen and is more likely to lead
to the inconsistency being fixed than a kill.
This way, the information remains valid after a split.
For clients on TS5 servers, the nick is used; this is
not much of a problem because these are on pseudoservers
and not assumed to change nick much at all.
- the number of messages blocked by target change on
this server since it was started
- the number of IPs currently subject to a a lower
target limit on this server (these expire over time)
This check sometimes blocks oper overrides (OMODE).
It does not stop any hacks that the channelTS check
already stops, because CHFL_DEOPPED is only set when
this server ignored an @ in an incoming SJOIN (the
SJOIN is then propagated without the @) and this
can only be because of a TS difference.
- Do not use hide_error_messages for certain "safe" ERRORs.
- If hide_error_messages hides an ERROR from a handshake,
send a server notice anyway, but without the message
text.
- Send server notices about ERRORs from handshakes network
wide if it was a remote connect.
