https://github.com/solanum-ircd/solanum https://cgit.space/~irc/github.com/solanum-ircd/solanum.git/atom/extensions?h=amdj%2Fmodules 2026-01-22T00:42:01Z 2026-01-22T00:42:01Z Ryan Schmidt 2026-01-21T22:08:55Z urn:sha1:6a1cd5ec8650ea4a8f47db64f8a4032cc4827c11 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 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 2026-01-13T17:12:32Z urn:sha1:8162cbe9d4f350da87a6eff02d06c804889b0d5f 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. 2025-10-10T19:09:40Z Ryan Schmidt 2025-09-01T22:29:55Z urn:sha1:cd99b5982442e8151ac15c3045d99abb12597283 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. 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-31T05:44:43Z urn:sha1:49e739e9318d8a6b96946e5125f9cc2c48b2b787 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. 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-18T23:07:26Z urn:sha1:a8e0049f8a01cf029c4af5d9fc0c864819be08b4 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. 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-18T22:41:37Z urn:sha1:309d69096e3f53590aadf90f817ecebce7267447 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 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-18T22:28:49Z urn:sha1:315266f6c3d0d7542caf97d454255d8d0e2589cf 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. 2025-10-10T19:09:40Z Ryan Schmidt 2025-08-18T21:33:12Z urn:sha1:e4ea11d8c7c5ddceadc6abd0d86b318b8cf1a1fd 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. 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).