Monthly General Meeting, May 2026

by moonmoon

Propositions and motions

Policy amendment to impose new requirements on bot and LLM usage

The meeting approved a network policy amendment that details where and how bots are allowed on the network via unanimous vote. The text of the amendment is detailed below.

Patch for policy change 
diff --git a/policies.md b/policies.md
index a5a1c15..804833c 100644
--- a/policies.md
+++ b/policies.md
@@ -198,6 +198,118 @@ sure that there is an easy way for channels to opt-out.
 If you wish to publish logs of a single conversation, please make sure you
 have gotten permission from all participants before doing so.
 
+## Bots
+
+User-administrated automated clients (bots) are allowed, providing they do not
+cause disruption to users or the normal functions of channels they are in.
+A bot cannot be its own administrator nor can it administrate other bots.
+Bots administrated by people who are not welcome as users are not allowed.
+
+A bot must be clearly labeled as a bot and be in some way attributable to
+its administrator(s), so that they can be contacted if the bot malfunctions.
+This can be done via a bot cloak or the bot's gecos (also known as realname).
+At least one of its administrators must be reachable via Libera.Chat;
+if the bot is a bridge bot, at least one of its administrators must be
+directly connected to Libera.Chat rather than on the other side of the bridge.
+
+Administrators of bots may be held responsible for what the bot outputs,
+even if not directly caused by the administrator. The administrator will be
+held accountable if they have refused to implement or make use of
+reasonable abuse prevention mechanisms.
+
+Users interacting with bots may be held responsible for the output that their
+interactions cause. Libera.Chat staff reserve the right to
+judge responsibility for policy-breaking output on a case-by-case basis.
+
+### Channel Joins
+
+Bots must not join channels without explicit permission from those channels'
+operators. Bots must not intentionally expose functionality that could result
+in them joining channels without permission from either users with
+invite privileges in those channels or the bot's administrators.
+
+Bots may not request permission to join channels. These requests should be
+made by the bots' administrators instead. Requests for permission must *not*
+be made via LLM processing.
+
+Bots may assume that they are permitted to join a channel upon receiving
+an invite from that channel. Administrators of bots may assume that they may
+configure their bots to join a channel if permission is granted in that
+channel's topic or `ChanServ` entry message. These assumptions may be made
+even if users without channel operator permissions can send invites or
+change the topic for the channel in question.
+
+Interactive bots should be clearly identified in channels. Bots that
+send messages should be given the voiced status where possible, as this
+exempts them from certain spam mitigation measures.
+
+### Use of Libera.Chat As Infrastructure
+
+Unless permission has otherwise been explicitly granted by Libera.Chat staff,
+Libera.Chat may not be used to facilitate communication between bots.
+This shall not apply to bots that incidentally process messages from other
+bots due to sharing a channel. As a rule of thumb, if your bots are using
+Libera.Chat to relay information that is not meant for a human to directly
+observe and process, your usecase is likely not permitted.
+
+## LLMs
+
+All LLM usage is governed by this policy. There is no exemption for
+"local-only" processing, as there is no reasonable method for verifying that.
+
+Bots and clients that have LLM-connected functions are permitted to connect to
+Libera.Chat. LLM-generated content may be transmitted via Libera.Chat
+providing that it is explicitly marked as such. LLM-enabled bots and clients
+may take input from Libera.Chat and output responses to Libera.Chat providing
+that the following obligations are met.
+
+Channels are considered opted-out of LLM presence by default. A disclosure of
+existing LLM presence does not satisfy the obligation for explicit permission.
+A topic explicitly inviting LLMs in, set by a named operator of the channel,
+counts as both opt-in and disclosure.
+
+Any LLM processing of a channel's content is considered
+[public logging](https://libera.chat/policies/#public-logging). Processing
+channel content or logs with LLMs requires obtaining permission from the
+channel's active operators before the collection of that data.
+
+LLM-powered bots shall be assumed to be capable of spuriously taking any
+action that the bot software allows the LLM to take,
+including joining channels, which bots are not permitted to do autonomously.
+The contents of any prompt given to the LLM do not preclude this assumption.
+Libera.Chat staff may deny access to known AI agents that can be
+trivially misconfigured to violate this policy.
+
+### Obligations of LLM bot administrators
+
+LLM-enabled bots must be accompanied in channels. A client controlled by the
+bot's administrator, or another consenting delegated human, must be present
+in each channel the bot joins.
+
+### Obligations of users of LLM-powered client features
+
+Client features, plugins, or scripts that use LLMs (e.g. for translation) must
+have per-channel and per-user configuration, allowing any individual channel
+or user to be opted in to or out of LLM processing.
+
+The client's user must disclose LLM use to each channel or private message
+participant before using LLMs in those contexts. It is recommended that
+messages with LLM contributions be differentiated from human-written messages
+in some way, to prevent confusion.
+
+### Obligations of channel operators
+
+Users must be made aware if they are interacting with, or their activity is
+being seen by, LLMs. This must happen as soon as possible, and it is the
+responsibility of the channel's management to ensure this happens.
+
+If a channel operator has consented to the presence of LLM-enabled bots or
+clients, the channel's topic or entry message must disclose that LLMs may be
+present in the channel.
+
+Known LLM-enabled bots must be highlighted in some manner. Channel topics and
+the use of channel status modes (e.g. voice) are recommended.
+
 ## Data retention and privacy policy
 
 You can find details about what data we collect, keep, and for how long

</details>

Other questions

Loading new modules: quarantine, tag_reply, tag_channel_context

The meeting discussed three Solanum modules that currently exist and whether they should be loaded onto the network. Brief descriptions of each module were given: quarantine is an oper-only feature that can restrict users from speaking in channels or PM except to opers and services (e.g. NickServ) until they register or identify to an account, tag_reply provides the IRCv3 +reply client tag, and tag_channel_context provides the IRCv3 +channel-context client tag. It was noted that network upgrades would need to take place before some of these modules could be loaded. The meeting decided that quarantine and tag_channel_context could be loaded, but that tag_reply needed additional development work regarding fallbacks for clients that only support the draft version of the client tag (+draft/reply) or that do not support message tags at all.