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.
