| Commit message (Expand) | Author | Age | Files | Lines |
|---|
| * | extensions/invite_notify: don't pass string to macro•••The macro does not use this parameter but nevertheless this is
the only module in the tree to pass a string to it, and if a
future macro were to use it, it could easily stringify the name
by using the # preprocessor operator.
amdj/invite_notify |  Aaron Jones | 2026-03-11 | 1 | -1/+1 |
| * | 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 |
| * | Create $PREFIX/var/solanum on install with --enable-fhs-paths•••On startup, bandb tries to create $PREFIX/var/solanum/ban.db, which fails if the directory does not exist.
|  Valentin Lorentz | 2026-02-03 | 1 | -0/+2 |
| * | Write data files to $PREFIX/var/lib/solanum instead of $PREFIX/var/solanum wi... | Valentin Lorentz | 2026-02-03 | 1 | -1/+1 |
| * | parse: fix crash•••The incoming_client and incoming_message globals were not properly
cleared after processing a numeric command. Ensure they are cleared by
not returning early after setting those global values.
Fixes: e2a499f | Ryan Schmidt | 2026-01-27 | 1 | -3/+3 |
| * | ircd/newconf.c: conf_set_general_hidden_caps: fix order of operations•••We should increment the number of capabilities to allocate space
for after freeing any existing capabilities, in order to prevent
the loop that frees them from overwriting the number.
Reported-By: Ryan Schmidt
| Aaron Jones | 2026-01-27 | 1 | -6/+10 |
| * | Add doing_version_confopts hook•••This hook allows modification of the confopts portion of a VERSION
response (i.e. the set of flags representing how the ircd was
configured).
Extension modules can use this hook to display additional confopts
without needing to edit m_version or add things to core in order to
share state with m_version.
| Ryan Schmidt | 2026-01-22 | 2 | -61/+115 |
| * | 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 | 5 | -37/+93 |
| * | Overhaul hooks documentation•••The new hooks documentation is now a comprehensive accounting of every
hook that exists in the solanum repo. The document includes changes to
hooks present in the (as of now unmerged) PRs #466, #478, and #482.
| Ryan Schmidt | 2026-01-21 | 2 | -137/+1214 |
| * | Add doing_info_conf hook and cleanup unused hooks•••doing_info_conf is called during INFO commands after all conf options
have been sent to opers. Modules can use this hook to expose any conf
options they define by sending relevant RPL_INFO replies to the oper.
This addition removes the final barrier to defining new ircd.conf
options inside of extension modules rather than requiring core changes
for extension configuration.
Additionally, some cleanup has been performed for hook definitions that
are not called anywhere inside of solanum. Three hooks were declared in
hook.h as extern int but were not defined or referenced in any other
file: iosend_id, iorecv_id, and iorecvctrl_id. The doing_admin,
doing_info, doing_motd, and doing_trace "spy" hooks were defined in the
module headers for those modules, however the modules never actually
invoked those hooks. All of the lingering declarations for these hooks
have now been removed as they weren't doing anything anyway.
| Ryan Schmidt | 2026-01-21 | 5 | -22/+7 |
| * | 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 | 3 | -119/+133 |
| * | Batch updates•••The extension example_module was extended to introduce a new
client-initiated batch type named test. This is primarily done to ease
testing of the client-initiated portions of m_batch, but also serves as
a useful sketch for how a module can register its own client-initiated
batch types.
The definition of struct BatchHandler was slightly modified to use a
callback function to determine if nesting is allowed. The callback can
additionally set a custom error message if desired when returning false.
The len and messages list in struct Batch no longer include the start
message, so a len of 0 indicates an empty batch. Because the start
message is still allocated and saved off, adjust anything that impacts a
client's pending_batch_lines by 1 to account for the implicit additional
message.
Empty batches now trigger the relevant batch handler. If a handler wants
to no-op on empty batches, it can do so but this allows additional
flexibility for handlers to still do something upon receiving empty
client-initiated batches.
| Ryan Schmidt | 2026-01-21 | 5 | -50/+85 |
| * | 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 | 2 | -21/+19 |
| * | 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 | 21 | -115/+1308 |
| * | Propagate tags in numerics from linked servers (#477)•••Previously, we handled numerics before running the message_tags hook or
setting the incoming_message and incoming_client globals, which meant
that tags received from linked servers would never be passed along to
clients. Now do both of those things before passing the numeric along so
we can propagate message tags in numerics.
This will, among other things, mean server-time now works with numerics
and solves an issue with implementing labeled-response in the future. | Ryan Schmidt | 2026-01-11 | 1 | -20/+18 |
| * | 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 |
| * | Replace git log usage with git rev-list (#479)•••This avoids issues with log.showSignature in serno.h |  hello-smile6 | 2025-12-10 | 3 | -5/+5 |
| * | Fix memory leak in sendto_match_servs (#465)•••Free the msgbuf cache after we're done. | Ryan Schmidt | 2025-10-23 | 1 | -0/+2 |
| * | Remote the `compressed` server flag•••This is a follow-up to 81531536aac9adb585c5a17b448aa0496bf68ebd where
the ziplinks feature had been ripped out. Unfortunately the value of
the `compressed` flag had been set to `0` instead of `-1`, or removed
entirely. This led to resetting a connect blocks flags being reset
whenever the `compressed` flag was being set.
When you'd set the flags (in this order) `topicburst, compressed, ssl`
you'd end up with just the `ssl` flag as setting `compressed` would
reset all of the flag back to zero (newconf.c:439) as
set_modes_from_table excepts `-1` to be passed as not-found / invalid
flag value.
With this (trivial) patch the log will contain a helpful line telling
operators that the `compressed` flag is unknown. It doesn't fail
config parsing/rehashing:
> Warning -- unknown flag compressed.
|  Andreas Rammhold | 2025-10-13 | 1 | -1/+0 |
| * | Fix CLIENTTAGDENY when there are no allowed tags (#461)•••The buffer was uninitialized and would produce garbage data. Ensure that
the buffer is an empty string when there are no allowed client tags. | Ryan Schmidt | 2025-10-11 | 1 | -0/+1 |
| * | Revert "msgbuf: duplicate the string during partial parse and constify line" ...•••This reverts commit 5b253939da8f6b0a44ce6787ed12e26450ac6a63 to fix a
memory leak:
```
==825564== 818 bytes in 4 blocks are definitely lost in loss record 616 of 648
==825564== at 0x4844818: malloc (vg_replace_malloc.c:446)
==825564== by 0x49CD7A9: strdup (strdup.c:42)
==825564== by 0x4888A2E: msgbuf_partial_parse (msgbuf.c:143)
==825564== by 0x489DA84: build_msgbuf (send.c:276)
==825564== by 0x489DA84: sendto_one_numeric (send.c:431)
==825564== by 0x48A3CD7: show_isupport (supported.c:181)
==825564== by 0x489A9F2: user_welcome (s_user.c:1433)
==825564== by 0x489B114: register_local_user (s_user.c:718)
==825564== by 0x488FC08: handle_command (parse.c:310)
==825564== by 0x488FC08: parse (parse.c:224)
==825564== by 0x488EEF8: parse_client_queued.part.0 (packet.c:67)
==825564== by 0x488F084: parse_client_queued (packet.c:49)
==825564== by 0x488F084: read_packet (packet.c:306)
==825564== by 0x4B3C47B: rb_select_epoll (epoll.c:199)
==825564== by 0x4B3716F: rb_select (commio.c:2038)
==825564==
[...]
==825564==
==825564== 3,012 bytes in 15 blocks are definitely lost in loss record 627 of 648
==825564== at 0x4844818: malloc (vg_replace_malloc.c:446)
==825564== by 0x49CD7A9: strdup (strdup.c:42)
==825564== by 0x4888A2E: msgbuf_partial_parse (msgbuf.c:143)
==825564== by 0x489D3CE: build_msgbuf (send.c:276)
==825564== by 0x489D3CE: sendto_realops_snomask (send.c:1431)
==825564== by 0x4887C0D: load_a_module (modules.c:712)
==825564== by 0x488801D: load_core_modules (modules.c:257)
==825564== by 0x488124A: solanum_main (ircd.c:664)
==825564== by 0x494DCA7: (below main) (libc_start_call_main.h:58)
``` | Val Lorentz | 2025-10-11 | 3 | -4/+4 |
| * | 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 |
| * | Address review comments•••- Remove static qualifier from a string that didn't need it
- Add some tests for trailing params with a leading colon as data to
ensure they are parsed/unparsed correctly
| Ryan Schmidt | 2025-10-10 | 3 | -1/+39 |
| * | Ensure duplicate tags only use the final value•••Per spec, individual tag keys MUST only be used once per message, and
implementations SHOULD disregard all but the final occurrence of a tag
key. As such, iterate over the user-provided tags in reverse order and
automatically discard tags that we have already approved.
Also, require that a client giving us a +typing tag has negotiated the
message-tags capability themselves.
| Ryan Schmidt | 2025-10-10 | 2 | -2/+10 |
| * | Fix typing module decl and send 417 in more cases•••The typing module declaration had a copy/paste error that has now been
corrected, and we now send 417 ERR_INPUTTOOLONG in cases where parsing
the line into a MsgBuf fails because it overflowed the 8191+512 byte
buffer while processing tags or the message origin.
| Ryan Schmidt | 2025-10-10 | 4 | -6/+18 |
| * | Address review comments•••Correctly sent ERR_INPUTTOOLONG if the incoming tags portion from a
client is too long. The previous calculation did not take into account
the fact we added null terminators after every tag key and value. Since
msgbuf_parse is used for both server and client input, we expose the
length of the original tags portion of the buffer in the MsgBuf struct
rather than abort msgbuf_parse if it is too long, since the only time
truncation is explicitly not allowed is for incoming tags from client
messages.
Additionally, make join_sep functional in format_client_tags().
| Ryan Schmidt | 2025-10-10 | 4 | -28/+33 |
| * | Documentation updates•••Add user help for the TAGMSG command. Additionally, update
reference.conf to include (almost) all extensions. The only extensions
excluded were those that are only useful when testing/debugging
(m_echotags), example modules (chantype_dummy, example_module), or
modules that should probably never be loaded in new networks
(ip_cloaking_3.0, ip_cloaking_old, m_mkpasswd).
| Ryan Schmidt | 2025-10-10 | 3 | -8/+85 |
| * | Update tests•••A number of tests needed to be updated to account for the fact that tags
are allowed to be up to 8191 bytes (or 4094 bytes for the
client-specified portion or server-specified portion individually). The
numbers in these tests were updated, and in some cases we now test both
server and client tags to ensure consistent behavior between both types.
| Ryan Schmidt | 2025-10-10 | 4 | -284/+1028 |
| * | extensions/tag_typing: Add +typing tag support•••The spec allows for three values: active, paused, and done, so filter to
only allow those three. No ratelimiting has been added as part of this
module, as the regular ratelimiting that applies to all sent messages is
likely sufficient for typing notifications.
| Ryan Schmidt | 2025-10-10 | 2 | -0/+71 |
| * | extensions/tag_message_id: Add msgid support•••Support the @msgid tag to label outgoing PRIVMSG, NOTICE, and TAGMSG
with a server-generated ID. Clients can make use of this ID for various
purposes, mostly in interaction with other (client-only) tags.
The msgid format was chosen so that it encodes enough state within the
id itself to be useful for eventual implementations of reply and
message-redaction. The format is as follows:
1. The character '1' to indicate this is message id format version 1
2. The timestamp the message was sent (milliseconds since epoch)
3. An incrementing counter value, for when multiple messages are sent
within the same second. The counter is seeded to a random number each
new second, so that it is not useful as a means of determining the
total number of messages sent by this server in a particular period
of time
4. The ID of the client sending the message
5. If the message is being sent to a channel, the base64-encoded name of
that channel
This metadata achieves multiple goals:
1. Message ids are sorted in lexically ascending order based on the time
they are sent, with the counter ensuring that earlier messages within
the same time increment are sorted before later messages. This could
potentially help in any sort of future shared message database to
achieve time-based queries, e.g. chathistory
2. When a client replies to a message, the server can partially validate
the msgid being replied to, ensuring that replies to a channel
message are only sent to that channel or replies to a user private
message are only sent to that user
3. The server can validate a client attempting to redact their own
message by comparing the client's ID and connection time against the
specified message's client ID and timestamp, allowing stateless
approval of self-redactions
4. The server can validate a chanop attempting to redact a message sent
in their channel by comparing the channel name and creation timestamp
against the specified message's channel name and timestamp, allowing
stateless approval of chanop-intiated redactions
5. No signing of messages is performed so a msgid cannot be used to
prove any particular message was sent by any particular client
| Ryan Schmidt | 2025-10-10 | 2 | -0/+144 |
| * | ircd/send.c: Better support for outbound tags•••There are now sendto_* functions that take explicit tags to pass to the
outgoing MsgBuf, in addition to any hook functions that listen to
outbound_msgbuf to add tags of their own. The outbound_msgbuf hook
function now receives a fully-parsed line, meaning it will have a
defined parameters array and (sometimes) origin. Hook functions can make
use of this to read message context when determining whether to add
tags, and can also manipulate the outbound MsgBuf as it will be unparsed
back into an IRC line after hooks have executed to be sent off.
Previously, only the tags portion was used and outbound_msgbuf had no
capability to examine or manipulate the rest of the outgoing message.
These functions also make use of the new MsgBuf caching layer that takes
a local and remote source. For functions that receive a static source as
part of the format pattern, NULL is used so that the cache inherits the
source from the parsed line.
In some cases, a sendto function may produce completely different
messages depending on the situation (e.g. sendto_channel_opmod which
behaves differently depending on if the remote server supports EOPMOD or
not, and if not, whether or not the target channel is +m). In such
cases, separate MsgBuf caches with separate MsgBufs were used. The
outbound_msgbuf hook is only executed once however, and all tags are
copied over to the other MsgBufs. This allows things like msgid to be
stable regardless of which variation is being sent out to which client.
Internal static functions beginning with underscores were renamed to be
sendto_*_internal instead. Identifiers with leading underscores in file
scope are reserved by the C standard, and their usage here was undefined
behavior.
| Ryan Schmidt | 2025-10-10 | 1 | -370/+487 |
| * | Cleanup areas impacted by client tags•••With the new TAGMSG support in m_message, filter now receives TAGMSG but
would choke on processing them due to not having a mapping from that
message type to a command name. Right now, no filtering is done on tag
contents because there is currently no tags that we support that take
arbitrary user-defined data (and thus would require filtering). This
fact does not change in the course of this patchset.
The client_tags code to register client tags for the CLIENTTAGSDENY
ISUPPORT message had some general formatting cleanup as well as a fix
for a segfault when removing support for a client tag if that client tag
was the last one being removed (causing the src and dest for strcpy to
be the same pointer) as well as a bugfix for the strcmp check that
would've caused it to overwrite the wrong client tag entry.
| Ryan Schmidt | 2025-10-10 | 2 | -13/+9 |
| * | 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 | 3 | -88/+212 |
| * | Refactor message_tag hook•••The original hook was defined in the (now-removed) cap_message_tag
module. This new hook lives deeper down in parse.c so that it fires on
all incoming tags for all incoming messages. The hook was renamed from
client_tag_accept to message_tag to denote that it is used for all tags,
including tags coming from server connections, and not just tags with a
client-only prefix.
The hook data contains two non-const fields for the capmask and approval
status. Since incoming tags lack a capmask entirely, this allows hook
functions that wish to keep the tag around to specify the capmask used
for propagating the tag to other clients and servers. The approval
status can take one of three forms: approve the tag, drop the tag from
the message (but still process other tags and run the command handler),
or drop the entire message (not processing any other tags and not
running any command handlers). It is expected when a hook function drops
the message that they'll send appropriate feedback to the client,
however the nature of that feedback will likely vary by hook function so
no default message is given to a client if their message is dropped.
The incoming_message global defined previously with cap_server_time now
holds the MsgBuf with the updated/sanitized list of tags rather than the
raw values specified by the client. Additionally, cap_server_time makes
use of this new hook to propagate the time tag into function callbacks
that support tag propagation. The implicit propagation still exists
since the majority of function callbacks do not support explicit tag
propagation, and that fact will not change in the course of this
patchset.
| Ryan Schmidt | 2025-10-10 | 4 | -10/+87 |
| * | Update MsgBuf for better tags support•••Note: Future commits within this PR update call sites to leverage these
changes. I opted to keep each individual commit smaller to make them
easier to review in series.
When parsing a line into a MsgBuf, we now keep track of whether the
final parameter had a leading colon or not, so that we can roundtrip
unparse it with said colon even if the final parameter lacks a space or
otherwise doesn't require the leading colon. solanum sends multiple such
messages and clients may be coded to expect colons in various
situations, so adding this roundtrip support maintains backwards
compatibility for when all outbound messages get parsed into MsgBuf and
then unparsed before being sent off.
The MsgBuf cache now keeps track of two messages: one with a "local"
source and one with a "remote" source. Many send functions, e.g. the
sendto_channel family, use ids for the sender when sending remotely but
use the hostmask or server name for local sends. When forcing outbound
messages into a parse/unparse loop we can no longer just ad-hoc assemble
strings together like the current linebuf code does, so instead we cache
both variants to avoid needless string formatting operations in tight
send loops.
Unparsing tags from a MsgBuf now enforces that the server tags and
client tags portions do not exceed 4094 bytes each, and that server tags
always come before client tags. Excess data is truncated.
| Ryan Schmidt | 2025-10-10 | 2 | -92/+152 |
| * | Increase tags to 8191 bytes and max count to 30•••If we receive an incoming message from a client that has over 4094 bytes
of tag data (not including leading '@' or trailing ' '), reject the
message with ERR_INPUTTOOLONG (417) per the message-tags spec.
Similarly, give the same numeric if the client specifies the new maximum
of 30 tags, since we can't distinguish between a client that gives us 30
tags and one that gives us more than 30. The spec says we are not
allowed to truncate tags at all, and having 30 means we could have
potentially truncated the incoming tag data.
| Ryan Schmidt | 2025-10-10 | 6 | -6/+17 |
| * | Remove cap_message_tags and reorganize Makefile•••Message tags support is being rolled into core rather than as a loadable
module because of the sweeping changes it requires, including at the s2s
protocol level for sending since the spec increased the size of the tags
portion from 512 bytes to 8191 bytes.
Also alphabetized the extensions Makefile to make subsequent patches
that add new tags cleaner.
| Ryan Schmidt | 2025-10-10 | 3 | -101/+16 |
| * | fix: remove cruft and fix msgbuf_parse |  Raito Bezarius | 2025-10-10 | 2 | -3/+1 |
| * | msgbuf: duplicate the string during partial parse and constify line | Raito Bezarius | 2025-10-10 | 2 | -3/+3 |
| * | 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 | 11 | -45/+206 |
| * | 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 | 7 | -9/+123 |
| * | isupport: add CLIENTTAGDENY | Raito Bezarius | 2025-10-10 | 1 | -0/+11 |
| * | tests/send1: we don't add tags to remote messages |  Ed Kellett | 2025-10-10 | 1 | -21/+21 |
| * | cap_server_time: data->client can be null | Ed Kellett | 2025-10-10 | 1 | -1/+1 |
| * | Propagate server-time implicitly (ugh) | Ed Kellett | 2025-10-10 | 3 | -0/+18 |
| * | tests/send1: @time is sent remotely now | Ed Kellett | 2025-10-10 | 1 | -1/+1 |
| * | cap_server_time: Don't stamp remote-sourced things | Ed Kellett | 2025-10-10 | 1 | -0/+3 |
| * | send: Make cap masks respect CAP_STAG for servers | Ed Kellett | 2025-10-10 | 1 | -19/+20 |
| * | msgbuf: Add msgbuf_get_tag | Ed Kellett | 2025-10-10 | 2 | -0/+15 |
Aaron Jones
Ryan Schmidt
Valentin Lorentz
hello-smile6
Andreas Rammhold
Raito Bezarius
Ed Kellett