https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/include/hook.h?h=amdj%2Fmodules 2026-01-21T17:09:43Z 2026-01-21T17:09:43Z Ryan Schmidt 2026-01-13T00:59:37Z urn:sha1:1b44c4de4d955156bc010fa8223031a14ab69202 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. 2026-01-21T17:09:09Z Ryan Schmidt 2025-12-01T16:54:56Z urn:sha1:0aac79db9d8747facb0fd59b673a437fa6f5696c 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. 2026-01-21T16:10:44Z Ryan Schmidt 2025-10-25T00:59:22Z urn:sha1:4cc9be1ddf1e14fc76bf433e23a3d528424b60ca - 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 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-18T22:09:25Z urn:sha1:49786f6404ae926909b157b524041e7521543e7d 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. 2025-10-10T19:09:40Z Raito Bezarius 2022-07-20T22:01:54Z urn:sha1:da7252cb7e96792fd68d88145fa061a561568444 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 2025-10-10T19:09:40Z Raito Bezarius 2022-07-19T14:20:33Z urn:sha1:59afa55b39a8067362dadcca937c8452a35c4e72 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. 2025-05-11T22:40:42Z daemoness 2025-05-02T16:30:19Z urn:sha1:b3d3796e690ce2482c1365d99e3329d5587b75d5 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). 2022-08-30T20:49:43Z David Schultz 2022-08-30T20:49:43Z urn:sha1:01fb744c405792dd3f0859a53f74cd4cb5fd166f 2021-03-01T15:45:03Z Ed Kellett 2021-01-29T11:54:12Z urn:sha1:8aadf0ce464a0e18e987a401a694d48d293953e6 2020-10-24T15:19:52Z Ed Kellett 2020-04-26T21:34:00Z urn:sha1:71f10f833fdb5bb140e756f8edbee3f42d540008