如果你刚开始接触互联网中继聊天（Internet Relay Chat，IRC）开发，首先应查看 IRC 核心规范 RFC1459 和 RFC2812。我们的一名成员还在 https://modern.ircdocs.horse/ 编写新的核心协议文档，可供参考。之后，我们的规范页面列出了 IRCv3 工作组（IRCv3 Working Group）制定的扩展。所有这些 IRCv3 扩展都向后兼容较旧的 IRC 客户端和服务器，路线图说明了正在推进的规范，大部分规范工作则在 GitHub 仓库中进行。

规范

这些是构成现代 IRC 的规范，以及 IRCv3 工作组定义的扩展。查看

工作组

IRCv3 工作组受权负责 IRC 客户端协议变更的原型设计、开发和测试。查看

常见问题

这里我们汇总了关于 IRC 和 IRCv3 工作组经常被问到的问题及回答。查看

简介

如果你刚开始接触 IRC 开发，首先应阅读 IRC 核心规范 RFC1459 和 RFC2812。我们的一位成员也在这里编写一份新的核心协议文档，查阅它可能会有帮助。之后，我们的规范页面包含了 IRCv3 工作组开发的扩展。

所有 IRCv3 扩展都向后兼容旧的 IRC 客户端和服务器。我们的路线图列出了正在进行中的规范，而规范工作主要在GitHub 仓库中进行。

如有其他问题，可以查阅我们的常见问题页面，其中有关于我们及我们工作的各种信息。

如果想和我们交流，讨论频道是 Libera.Chat 上的 #ircv3[网页聊天]。

IRCv3 特性

• 使用 SASL 标准化账户登录，加快注册和身份验证。[3.1][3.2]
• 提供其他客户端的账户信息，以便开发更高级的客户端功能。[1][2][3]
• 可为每条消息附加可选元数据，让扩展开发更轻松、更标准化。[链接]
• 即时离开通知，让用户更快知道其他用户离开或回来。[链接]
• 显示消息收到的实际时间，改进 IRC bouncers 的历史回放。[链接]
• 将相关消息分组，简化这些消息的折叠和向用户展示。[链接]

我们正在进行的工作

• 标准化账户注册与验证，让客户端能为最终用户提供更好的界面。[链接]
• 为客户端提供标准化的方式来识别、访问和查看聊天历史（由 bouncers 或服务器提供）。[链接]
• 提供一种机制，让客户端能自动检测、切换并持续使用安全连接。[链接]
• 允许使用 Unicode 昵称和频道名，改善国际用户的聊天体验。[链接]
• 客户端头像，用于在图形客户端中显示。

参与组织

讨论气氛怀旧而务实：许多人对 IRC 三十多年仍在运行、协议简单且仍有使用场景表示欣赏，甚至因反感 Discord 的年龄验证监控而想回归 IRC。但分歧主轴在于 IRC/IRCv3 是否还能赶上现代需求——一方认为渐进落地的扩展和去中心化现代客户端仍有希望，另一方则指出它长期停滞、客户端支持割裂，且缺少文件托管、历史消息和移动端同步，反而不如完善 Matrix 或使用 Discord、RocketChat 等替代品。

认为 IRC 简单、长寿且仍有回归价值

• IRC 在 fidonet、gopher 等老互联网协议中几乎是唯一仍被日常使用的，三十五年后大体保持原样，这种韧性令人佩服。（较多人）
• 协议简单是 IRC 的美感所在：个人开发者能几周内为 Twitch 聊天做出客户端，也有人想自研 iOS 原生客户端来弥补移动端体验。此外，有人因反感 Discord 的年龄验证监控而回到 IRC，mIRC 也曾把不少人带进计算机和编程。（较多人）
• 已有人基于 IRCv3 做出联邦式、去中心化且带 Discord/Slack 体验的聊天（如 Parley、Ahoy），说明 IRC 并非不能现代化。（少数人） > 列表里竟然没有 mIRC，好吧。（@pjmlp）

认为 IRCv3 进展迟缓、路线图陈旧，难以赶上现代需求

• 看 IRCv3 的路线图，多数问题还停留在 2020/2021 年（甚至有一个是 2017 年、Discord 刚出现时），有人讽刺要等到 Dyson swarm 那种文明等级才能做完。（少数人）
• IRC 曾经很棒，但在今天的替代品面前很难回春；现代开源替代品已经提供人们需要的功能，IRCv3 追赶起来只会难上加难。（较多人）
• 在 IRCv3 频道里待一两周就会明白它确实需要新领导力：频道里多是宁愿 IRC 保持不变的抱怨者，但“IRC 仍远远落后于其他所有东西”这一批评并不会因为批评者被叫作氛围程序员而失效。（少数人） > IRC 曾经很棒，但今天的替代品已经提供人们需要的功能，IRCv3 要追上只会难上加难。（@7bit）

认为 IRC 缺少媒体分享、消息持久化和多端同步等现代刚需

• 想在 IRC 里发截图或视频很不合理：只因要发图，就得换一个还支持语音通话的聊天平台，而大家只是想把图片直接粘贴进聊天。（较多人）
• 现代社区的核心用法是在不同时区异步发布媒体内容，别人稍后回复，并能搜索历史记录；IRC 做不到，自托管场景下 RocketChat 之类已能提供相近体验。（较多人）
• IRC 服务器没有文件或视频托管，讨论又是临时的：要么一直在线，要么靠保活代理或在 VPS 里用终端复用会话挂 IRC 客户端；所谓历史消息扩展在现实里几乎没见过。（较多人）
• 若真要从 Discord 迁回 IRC，会怀念移动端访问和多设备账号同步。（少数人）
• 若客户端能支持图片/视频嵌入，以及带视频和屏幕共享的语音聊天，IRC 会更有吸引力。（少数人）
• 有人希望 IRC 支持 WebSocket 传输，以适配现代 Web 使用场景。（少数人） > 在 IRC 上既不能托管视频文件，讨论又是临时的，想看别人后来的回复就只能一直在线或自己挂保活代理。（@badsectoracula）

认为 IRCv3 的真正问题是可选扩展太多、客户端支持割裂

• IRCv3 有数不清的可选扩展，不同客户端支持程度不一，导致同一段对话在不同人眼里不一样：有人能看到表情回应和“回复”，有人看不到，体验非常混乱。（少数人） > IRCv3 有大量可选扩展，不同客户端看到的是不一样的对话，有人看得到表情回应和“回复”，有人看不到。（@Retr0id）

认为 IRCv3 功能已在部分客户端渐进落地，不应只看路线图

• 部分服务和客户端其实已经实现了许多 IRCv3 特性（如 IRCCloud、功能完整的 Ahoy），所以现代化能力是渐进落地的，而非等待某个大版本“大爆炸”式到来，只是各客户端支持进度不同。（少数人） > 像 IRCCloud 这样的服务其实已经实现了很多 v3 功能，并不是要等某次大发布才会突然出现，只是各客户端支持进度不同。（@dewey）

有价值的补充

• RobustIRC 是从服务端改动入手的项目，目标是强化服务器到服务器之间的链路，并改善这对已连接客户端造成的影响。
• Twitch 的直播聊天底层仍然使用 IRC，因此有人专门写了 IRC 客户端来更轻松地追踪直播时的刷屏聊天。
• iOS 上缺乏好用的原生 IRC 客户端，常用的 Goguma 只是把安卓客户端编译到 iOS；IRC 协议简单到让开发者想自己实现，以适配 Liquid Glass。