| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | Add no-implicit-names client capability•••This has been recently ratified and suppresses NAMES output during
channel joins when enabled, providing for a decent chunk of bandwidth
savings.
|  Ryan Schmidt | 2026-03-19 | 1 | -1/+2 |
| * | Remove channel::kick_on_split_riding•••This feature had numerous pitfalls (such as not checking +beI) and
services does it better than we can. Remove it and alert opers that the
feature no longer exists if they had it configured.
| Ryan Schmidt | 2026-03-17 | 1 | -41/+0 |
| * | Adjust unsigned int -> uint64_t for all caps•••The previous commit addressed the issue with (most) function signatures,
but forgot to update the caps themselves to be 64-bit. This fixes that,
and finishes the remaining overlooked function signatures.
| Ryan Schmidt | 2026-03-17 | 1 | -1/+1 |
| * | Separate client vs server caps•••Instead of overloading the same field in a LocalUser, have separate
fields for client caps vs server caps. While only one of these will ever
be nonzero, it reduces error by making it explicit which set of caps is
being checked. IsCapable and friends have been split as well, to
IsClientCapable and IsServerCapable. Finally, both fields have been
updated to uint64_t (server caps were approaching the current limit) and
all APIs that reference caps updated to uint64_t as well (no more
signed/unsigned mismatches).
| Ryan Schmidt | 2026-03-17 | 3 | -13/+10 |
| * | Make TAGMSG behave like NOTICE for errors•••We explicitly do not send error numerics to clients for NOTICE in most
cases, instead silently discarding the command. Give this treatment to
TAGMSG across the board as well. Previously, this was the case for
TAGMSG without tags but was not applied for TAGMSG that had tags but
otherwise had issues (e.g. +m channel and the user is not +ov). This
prevents spamming users whose clients send automatic TAGMSG with errors
they can do nothing about.
| Ryan Schmidt | 2026-02-12 | 1 | -17/+17 |
| * | Pass msgbuf to PART's privmsg_channel hook and propagate PART tags•••The privmsg_channel hook gained a new msgbuf member which was
uninitialized in m_part. Properly pass the msgbuf to that parameter and
propagate any tags set by the hook to downstream servers.
This requires introducing sendto_server_tags(), and I refactored
sendto_server() to call the same helper internal method as
sendto_server_tags(). I took the opportunity to update the method to use
msgbuf instead of linebuf directly (meaning sendto_server() now calls
outbound_msgbuf).
Fixes #484
| Ryan Schmidt | 2026-01-22 | 1 | -19/+19 |
| * | Fix msgid tags with echo-message•••msgid generation has been moved to the privmsg_user and privmsg_channel
hooks, which are called on every normal PRIVMSG/NOTICE/TAGMSG. They are
not called when messaging user@server, opers@server, or mass-messages
and as such none of those things will have msgid attached. This seems
fine as user@server is rejected by solanum and exists solely for
messaging pseudoservers, opers@server is turned into a snote, and
mass-messages are oper-only and thus unlikely to need anything that keys
off msgid in the future.
Moving this solves the interaction with msgid and echo-message. Now, we
ensure that an echoed message always has a msgid, and that msgid is
always the same as the msgid shown to other clients.
This requires expanding the hook_data structures for those two hooks.
While a core restart is not needed, attempting to reload tag_message_id
before reloading m_message may cause crashes. When updating your
servers, please reload m_message first.
| Ryan Schmidt | 2026-01-21 | 1 | -51/+56 |
| * | Avoid making spurious netjoin batches•••If a server being netjoined to us is introducing additional downstream
servers from it, those servers won't themselves be sending us bursts. As
such, we can safely suppress sending a BATCH to clients for those
additional servers.
| Ryan Schmidt | 2026-01-21 | 1 | -0/+6 |
| * | Include AWAY and status MODEs in netjoin batches•••AWAY is burst to away-notify clients and status MODEs (+o and +v) are
burst to all clients on the channel. Excluding these from the batch
means that clients may opt to process these before the batch completes,
then get confused because they have no records of those nicknames
existing or being members of the channel. Including both in the netjoin
batch solves these concerns, although the netjoin batch spec is silent
on whether we're allowed to put non-JOIN commands in that batch.
| Ryan Schmidt | 2026-01-21 | 1 | -18/+16 |
| * | Add batch support•••- Add "batch" client capability
- Support sending netsplit/netjoin batches
- Support receiving BATCH from clients and remote servers
- Support for modules to define supported batch types for incoming
batches
- Add "message_handler" hook to override the handler for a particular
incoming message
- Add technical and user-facing documentation for batches
- Add some more sendto_* overloads that support tags which were missing
from the initial message-tags implementation but turned out to be
needed
| Ryan Schmidt | 2026-01-21 | 1 | -2/+119 |
| * | Stop sending ERR_NOTEXTTOSEND on empty TAGMSG (#476)•••Per the message-tags spec, clients are allowed to send tags blocked by
CLIENTTAGDENY, and some clients make use of this allowance to send tags
that are otherwise stripped out (e.g. +typing if that module is not
loaded). If a TAGMSG did not have any client tags after processing, we
previously returned ERR_NOTEXTTOSEND (412) however this results in a
fair amount of spam in the server buffer of such clients. Make the
command silently fail instead.
An open question remains on how this interacts with echo-message, as the
spec is not well-written to cover what happens during failure/error
cases. A strict reading of the spec would require an echo-message on
every received PRIVMSG/NOTICE/TAGMSG, including cases where we are
already sending an error numeric. This does not seem intended, and would
complicate labeled-response by requiring a batch in error cases.
A looser reading of the spec seems to permit not sending any
echo-message in the case that messages are filtered out (as the portion
of the spec allowing "fake messages" is a MAY). Since we currently do
not send any echo-message for empty NOTICE (and do not send any numerics
either), apply the same treatment for empty TAGMSG: the server silently
drops the command and does not echo anything back to the client. | Ryan Schmidt | 2026-01-11 | 1 | -3/+0 |
| * | Remove duplicate definition message-tags CAP•••It is defined in s_serv.c so it doesn't need to additionally be defined
in modules/core/m_message.c. Support for receiving client tags is baked
into parse.c and other core files, so the definition in s_serv.c is the
right place for it.
| Ryan Schmidt | 2025-10-10 | 1 | -1/+0 |
| * | m_message: Implement message-tags and TAGMSG•••The CAP_STAG server capability and the CAP_TAGS server capability
introduced by m_message are redundant, so get rid of CAP_TAGS and update
the comment for CAP_STAG to indicate what it is for. Additionally,
define the message-tags client capability in m_message.
A lot of new sendto_* functions were introduced that take an explicit
array of tags to attach to the outgoing message. New functions were
preferred over updating existing functions in order to maintain
compatibility with non-tags-aware code in both the API and ABI layers.
The updated definitions of these functions will be provided in a
subsequent patch in this PR; however I felt the declarations would be
useful in reviewing the changes to m_message.
A TAGMSG with zero client-only tags is rejected with 412
ERR_NOTEXTTOSEND. While the precise message of that numeric is a little
bit misleading, it was the closest existing thing and matches what we
send off when a PRIVMSG contains no text. The message-tags spec does not
specify any particular error when a TAGMSG contains no tags (indeed it
has a non-normative example where such a TAGMSG is propgated). The spec
also allows for server-side moderation of tags, however, and not
propagating completely useless messages is a valid use of those
moderation powers.
General cleanup of the file was performed as part of this patch.
| Ryan Schmidt | 2025-10-10 | 1 | -83/+190 |
| * | message-tags: facility to manipulate client-tags•••It provides for hook facilities to client-only tags:
- messages can be dropped silently ;
- messages can be edited ;
- messages can be stripped from a client-only tag
|  Raito Bezarius | 2025-10-10 | 1 | -12/+1 |
| * | m_message: proper tag propagation•••This introduces an handler to accept or not the propagation of a tag.
Basic sketch API is provided for modules to hook for providing their own
policy for specific tag propagation.
| Raito Bezarius | 2025-10-10 | 1 | -9/+38 |
| * | Add dedicated hook data type for can_create_channel•••hook_data_can_create_channel includes the name of the channel being created,
which is necessary for any non-trivial restriction of channel creation
as well as sending correct error messages.
The new hook data matches the layout of the previous hook data,
taking advantage of a disused pointer field in hook_data_client_approval
as used by callers of the hook (m_join).
|  daemoness | 2025-05-11 | 1 | -1/+2 |
| * | MODRESTART/MODRELOAD: Defer reloading more quickly•••Commit 41390bfe5fa3895b8dee fixed a bug whereby the processing
of a MODRESTART command could result in a crash. The approach
taken in this fix was to defer the reloading of all modules
so that the call stack does not contain functions located in
modules that are being reloaded. It did this by scheduling a
one-shot timer event for 1 second in the future, in the absense
of any better deferral mechanism at the time. Timers are
processed by the event loop, which is core to IRCd and cannot
be reloaded.
Commit 59ea3c6753e80d051b20 introduced a mechanism to defer the
execution of a function until all events have been processed by
the event loop, in order to fix a REHASH bug that could result
in a crash due to closing and reopening listener sockets with a
pending socket connection event to process after the REHASH was
completed.
Rework commit 41390bfe5fa3895b8dee to use the new deferral
mechanism introduced by commit 59ea3c6753e80d051b20 and do the
same for module reloads.
|  Aaron Jones | 2023-11-20 | 1 | -2/+2 |
| * | client: refactor del_all_accepts to allow skipping own accept list•••This allows reusing this function for other uses that just need to
remove this client from others' accept lists on nick change and not have
duplicates of this code everywhere
|  Doug Freed | 2023-11-06 | 1 | -16/+1 |
| * | Add oper:free_target (#374)•••Co-authored-by: Ed Kellett <e@kellett.im> |  Jess Porter | 2022-09-26 | 1 | -1/+1 |
| * | EBMASK capab, to burst BMASK metadata (#354) | Jess Porter | 2022-08-20 | 1 | -49/+88 |
| * | Cast time_t to long long when printing |  Matthew Martin | 2022-07-01 | 2 | -2/+2 |
| * | ERR_USERONCHANNEL when following a forward is missing a param | jesopo | 2021-08-15 | 1 | -0/+4 |
| * | modules/core/m_message.c: align comments about idle time (#252) | Aaron Jones | 2021-07-18 | 1 | -4/+3 |
| * | kick,remove: don't confuse source and target membership |  Ed Kellett | 2021-07-13 | 1 | -8/+8 |
| * | Keep propagated bans in a dictionary, not a list | Ed Kellett | 2021-06-08 | 1 | -6/+7 |
| * | Add an s2s cap for ECHO (#141) | Ed Kellett | 2021-04-20 | 1 | -1/+11 |
| * | /accept list should track nick changes when you share channels (#96)•••* move has_common_channel to s_user.c
* don't remove clients from /accept on NICK when there's a common channel
Co-authored-by: Ed Kellett <e@kellett.im> | jess | 2021-01-24 | 1 | -3/+17 |
| * | chmode: end the grace period more intelligently (#84)•••We were ending the flood grace period for any channel mode command other
than `MODE #foo [bq]` by means of a hardcoded check. I've moved that to
after we parse the mode string, so we can correctly identify all
requests to change modes and end the grace period on exactly those.
It would have been entirely possible to move the check even further down
and flood_endgrace on only mode commands that *actually* change modes,
but I don't like the idea of making it sensitive to external conditions. | Ed Kellett | 2020-11-30 | 1 | -7/+0 |
| * | Get rid of hub_mask/leaf_mask | Ed Kellett | 2020-11-14 | 1 | -133/+0 |
| * | make more snotes L_NETWIDE | jess | 2020-11-08 | 5 | -51/+46 |
| * | m_message: Initiate message echo on target server | Ed Kellett | 2020-11-06 | 1 | -4/+53 |
| * | Remove shared blocks | Ed Kellett | 2020-11-01 | 2 | -42/+0 |
| * | m_message: global snote when massnotice is used | Ed Kellett | 2020-10-27 | 1 | -0/+8 |
| * | Unify oper:{global,local}_kill | Ed Kellett | 2020-10-25 | 1 | -10/+2 |
| * | Implement the solanum.chat/identify-msg vendor cap | Ed Kellett | 2020-10-16 | 1 | -0/+64 |
| * | Innovation by sed | Ed Kellett | 2020-10-15 | 1 | -1/+1 |
| * | Replace most checks for +o with oper:general•••I'm preparing to PR a succession of privs changes with the ultimate goal
of severely limiting the scope of the binary oper/user dichotomy and
move conceptually distinct oper functions into their own privs.
Accomplishing this is a non-trivial task, and can wait, but it's
inconvenient now to have such functions enabled by the same mechanism
that grants any privs at all--so I'm moving all of them to a
transitional priv with the intention of eroding that later.
| Ed Kellett | 2020-08-04 | 6 | -12/+14 |
| * | message: run privmsg_user hook on both source and target |  Ariadne Conill | 2020-07-09 | 1 | -12/+12 |
| * | message: remove hardcoded +G logic | Ariadne Conill | 2020-07-09 | 1 | -70/+2 |
| * | message: remove hardcoded +R logic | Ariadne Conill | 2020-06-26 | 1 | -11/+2 |
| * | Merge pull request #340 from ophion-project/upstream/hook-channel-lowerts•••join: add channel_lowerts hook |  Aaron Jones | 2020-06-26 | 1 | -0/+9 |
| |\ |
|
| | * | join: add channel_lowerts hook | Ariadne Conill | 2020-06-26 | 1 | -0/+9 |
| * | | Merge pull request #334 from edk0/massnotice•••Remove the massnotice wildcard restriction | Aaron Jones | 2020-06-25 | 1 | -17/+0 |
| |\ \
| |/
|/| |
|
| | * | Remove the massnotice wildcard restriction | Ed Kellett | 2020-06-07 | 1 | -17/+0 |
| * | | Add client_quit hook | Ed Kellett | 2020-05-23 | 1 | -8/+23 |
| |/ |
|
| * | m_modules: make modreload work like restart•••/modrestart used to be implemented as a normal command and could crash
when used remotely because it would reload m_encap, which was on the
call stack at the time. This was fixed in 41390bfe5f. However,
/modreload has exactly the same problem, so I'm giving it the
same treatment.
Incidentally: This bug was first discovered in ircd-seven, where the
`/mod*` commands themselves live in the core, so m_encap was the only way
the crash could happen (and it didn't most of the time, because m_encap
would only be moved if you got unlucky). But `/mod*` are in modules in
charybdis, so /modrestart would have unloaded the code it was in the
middle of executing. With that in mind, I'm not sure how it ever
appeared to work.
| Ed Kellett | 2019-11-17 | 1 | -33/+5 |
| * | Deferred capability notifications from modules•••Reloading modules sends CAP DEL followed by an immediate CAP NEW:
:staberinde.local CAP * DEL :account-tag
:staberinde.local CAP * NEW :account-tag
This isn't very nice. /modrestart is particularly bad. In order to avoid
doing this, we remember the capability set at the beginning of module
operations, compare that with the set afterwards, and report only the
differences with CAP {DEL,NEW}.
| Ed Kellett | 2019-09-07 | 1 | -0/+12 |
| * | m_ban: check only the added K-line | Ed Kellett | 2019-04-27 | 1 | -14/+1 |
| * | m_nick/m_sasl/m_user: restore check for mixing of client and server protocol |  Simon Arlott | 2018-08-15 | 1 | -1/+1 |
| * | m_pass: store unverified SID in preClient for use in m_server | Simon Arlott | 2018-08-15 | 1 | -15/+18 |
Ryan Schmidt
Raito Bezarius
daemoness
Aaron Jones
Doug Freed
Jess Porter
Matthew Martin
Ed Kellett
Ariadne Conill
Aaron Jones
Simon Arlott