irc（freenode）のChanservコマンドと/ modeコマンドの違いは何ですか
過去5年間IRCを使用しているにもかかわらず、少し混乱しています。ChanServボットがあり、それを使用して操作（ACL変更）を実行できます。 /msg ChanServ #channel-foo-bar <nick> +Fを実行するユーザーの創設者ステータスを指定しますが、誰かを禁止したい場合はChanServを使用し、人に+bを設定しますが、私の懸念は、なぜ人（+q）は/mode #channel-foo-bar <nick> +qを実行する必要があります。ChanServは人ごとのACLビットを制御するために使用され、/modeはチャネルごとのオプションを設定するために使用されています。しかし、私は間違っていたようです。なぜ、ChanServを使用して+qフラグを設定できないと言うのですか？
さて、両方のクワイエットとの禁止は、実際には/ mode（それぞれ/mode +qと/mode +b）を介して設定されます。 ChanServを介して誰かに+ bフラグを「付与」することは、禁止された人が戻ってきたときはいつでも+ bモードを設定するように指示するだけです（チャネルからそれらを蹴ります）。
/mode +bとChanServのフラグを使用する主な違いは、後者が永続的に保存されることです（以下の完全な説明を参照）。
追加機能として、ChanServを使用すると、禁止にメモと有効期限を設定できます。これはflagsからは利用できませんが、/msg chanserv akickからこの機能にアクセスできます。チャネル運営者は、誰かが禁止された理由と期間を知ることが役立つと感じることがよくあります。そのために共有のgoogle-docを保持する必要はありません。
背景：ほとんどのIRCネットワーク永続的なストレージはありません。ユーザーの「アカウント」はありません。すべてのチャネルは一時的なものであり、モードと禁止リストがあります。チャンネルに人がいる間だけメモリに保持されます。opステータスを取得した場合、チャンネルにいる間だけ持続します。離れたり切断したりすると、誰かがもう一度/ opする必要があります。サーバーが再起動した場合、ゼロから再同期します。network全体が再起動すると、すべての状態が失われます（2012年後半にEFnetで発生したように）。
（例外はありますが、これは通常のケースです。）
サービスボット（ChanServ）は、このストレージを完全に別個のプログラムで提供し、従来の「ボット」または単なるスクリプトクライアントのように機能します。 ChanServで設定したすべてのフラグは、実際にはネットワークに直接影響を与えるわけではありません。ChanServに、ユーザーに代わっていくつかの/ modesを設定するように指示するだけです。 （チャネルオペレーターの場合は、これらの/ modeを自分で設定できます。一時的なものです。）
したがって、freenodeに+ oまたは+ Fフラグがある場合、チャネルへの直接アクセスは変更されません。 ChanServを介した間接アクセスを提供します。 + oフラグは、ChanServに自分で/mode +oを要求できるようにするACLです。 + Fフラグは、他の人にフラグ/ ACLを与えることができるACLです。
なぜない ChanServにはユーザーをミュートするための+ qフラグがあるのですか？まあ、それはできたが、まだ誰もそれを実装していません。
議論の1つは、ミュートは一時的なものであることが多く、ChanServに保存する必要は実際には必要ないのに対し、完全な禁止は永続的であり、永続ストレージのより良い使用。
もう1つの理由は、サービスソフトウェアがいくつかの異なるタイプのIRCサーバーで動作し、すべてのカスタム拡張機能を調整するように作成されていることです。完全な禁止のみがIRC –freenodeには+qモードとしてミュート（クワイエット）がありますが、これは非標準の追加です。
その他のIRCサーバーの拡張子は異なります。たとえば、+qのより一般的な意味は、「チャネル所有者」ステータスです。これは、ChanServスタイルの所有者を意味するのではなく、実際にはいくつかのボーナス付きの通常のチャンネルアクセス。これは、「op/voice /」の代わりに、FooneticまたはRizonで確認できます。ペオン「通常」には「所有者/管理者/操作/ハーフホップ/音声/通常」があります（もちろん、ミュート/クワイエットは別の文字を使用する必要があります）。
したがって、freenodeのChanServにミュート用の+qフラグがない主な理由は、他のネットワークタイプに「所有者」レベルを実装するためにすでに同じフラグを使用しているためです。
（ネットワークがベースサーバーソフトウェアを切り替えても、同じサービスソフトウェアとアカウントデータベースを維持する場合が多くあります。これが発生した場合、サービスが以前のすべての「+ q（チャネル所有者）」エントリをに変換することは望ましくありません。 「+ q（ミュート）」エントリ...）