USuser3939382·Oct 11, 2026
It is in draft https://github.com/ircv3/ircv3-specifications/pull/562
Good v3 clients like The Lounge also offer it
In IRCv3ircv3
ircv3-specifications
Web Development2014–2026
ircv3 / ircv3-specifications
ircv3-specifications
IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
17Distinct people
22Mentions
1Explicit recommenders
880GitHub stars
What to know before exploring
What it is
IRCv3 specifications | Roadmap: https://git.io/IRCv3-Roadmap | Code of conduct: http://ircv3.net/conduct.html
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
As much as I love IRC, this argument seems to me to not be that different from the "just use rsync/ftp" Dropbox argument. There is this IRCv3 extension proposal, though:…
insertnickname used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year22 dated mentions
Observed mentions: 2014-03-10 15:29:20 UTC to 2026-10-11 17:36:24 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 5 | 2 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
22 sources> Unfortunately, it wasn't clear how services operate, though
It's also not clear for us! We're considering using a regular replicated database backend with multiple service nodes accessing it. Making the service nodes replicate directly through the network is also an option.
> Is there still a benefit to having more than one server?
Good question. I'm not a staffer at Libera so I don't know, but they believe they need multiple servers. If nothing else, it keeps latency low between clients and servers no matter the client's continent.
> That means support for posting images and videos, audio/video chat, offline history, easy switching between desktop and phone, deep and granular admin controls, etc. I'd love for there to be an open source & open protocol option here, but I'm terrified to even imagine an RFC that implements all of this in
Read the rest
a way that works in practice.
There are already specs for most of this stuff. Images and videos are through sharing URLs freely and there's https://github.com/progval/ircv3-specifications/blob/filehos... to tell client where they can upload media (I wrote it as a joke, but there are a couple implementations now???). Video/audio chat won't happen, because it's just too hard. https://ircv3.net/specs/extensions/chathistory for offline history already has a decent number of implementation. And easy switching is going to be tough but there has been work on it from https://soju.im/ (read markers, synchronizing PMs) that we can reuse.
"deep and granular admin controls" is probably going to be through non-standardized commands as is tradition, so servers can freely innovate and there isn't much to gain through standardization. https://github.com/ircv3/ircv3-specifications/pull/484 would help build GUIs for new custom flags, though.
Working on it: https://github.com/ircv3/ircv3-specifications/pull/471
In Ergo – modern IRC server written in GoHistory is possible with current IRC tech & spec, but I think the cost (GDPR compliance etc.) will be a challenge for networks run by volunteers. Even before the spec work, IRCCloud has been an option for a long time. Now there is a chat service for paid users of Sourcehut: https://sourcehut.org/blog/2021-11-29-announcing-the-chat.sr...
Ticket for ratifying CHATHISTORY, tracking implementations:
https://github.com/ircv3/ircv3-specifications/issues/437
In IRC technology news from the second half of 2021There is a work in progress specification for push notifications: https://github.com/ircv3/ircv3-specifications/pull/471
In IRCv3 Spec round-upClarification, I'm the one of the maintainers of Oragono [1], an IRCv3 server project, but I don't speak for IRCv3 as a whole. In fact, I think my take is somewhat controversial in the IRCv3 community. But here goes:
1. Most of the big problems with IRC as a protocol (nicknames, ghosting, missed messages) come from the assumption that the core of the network should be stateless. If the core of the network is stateless, you can't have nickname reservation, you can't transparently attach two clients to the same nickname, and you can't replay missed messages to people who were disconnected (hence the need for clients to maintain a TCP connection to the server at all times, hence netsplits being disruptive, etc.).
2. Conventional IRC setups solve some of these problems by adding a single privileged node, the "services framework" (Anope and At
Read the rest
heme are examples), that stores some persistent state (typically, nickname and channel reservations). This actually abandons the high-availability properties of the original IRC design: it is theoretically possible to design a highly available services framework (using a clustered database or whatever) but AFAICT none of the frameworks that currently exist are HA.
3. Oragono is a single instance that provides an integrated IRC server, services framework, and "bouncer" (history retention and playback). Client connectivity problems are solved by allowing transparent reattach to the original nickname after authentication with SASL, then automatically replaying history. (Client support for this is still patchy [2], but anything that supports znc.in/playback [3], like Textual, will work well; you can also configure Oragono to try and track what you missed and replay it on reconnection.)
4. To make Oragono highly available, it can be deployed in Kubernetes (virtualizing the embedded database file and the external IP, spinning up a replacement instance on failure).
[1] https://github.com/oragono/oragono
[2] https://github.com/ircv3/ircv3-specifications/pull/393
[3] https://wiki.znc.in/Playback
Fortunately, "IRC with a few tweaks" is being actively developed under the name IRCv3 and it seems that scrollback support is defined by a combination of these specifications:
https://ircv3.net/specs/extensions/batch/chathistory-3.3
https://github.com/ircv3/ircv3-specifications/pull/393/files
In Discord is not an acceptable choice for free software projectsWell there's still active discussion on how the extension should work. This needs to be squared away first since you'll need all server software and client software to agree.
https://github.com/ircv3/ircv3-specifications/pull/393
In Absence of certain features in IRC considered a featureAfter doing some digging, it looks like there's some people working on a new spec for IRC version 3. One of the additions is the ability to request chat history from the server. Though I'm not sure when it will be implemented since it's been on the table for 4 years now.
https://github.com/ircv3/ircv3-specifications/milestone/4/
In Absence of certain features in IRC considered a featureIt's definitely something that people have looked at, eg:
https://github.com/ircv3/ircv3-specifications/pull/292
In Mozilla is giving up on their IRC serverAs much as I love IRC, this argument seems to me to not be that different from the "just use rsync/ftp" Dropbox argument. There is this IRCv3 extension proposal, though: https://github.com/ircv3/ircv3-specifications/pull/292
In Slack Is Buying HipChat from Atlassianhttps://github.com/ircv3/ircv3-specifications/pull/292
Kiwi IRC actually implements this and has a ZNC module being released soon for it. Hopefully soon, other bouncers.
These type of specs and actually getting them implemented in clients and servers is exactly the type of things the irc.com foundation will be supporting.
In IRC.com Bought by London Trust Media, Pledges an IRC RevivalIt's on the horizon, though: https://github.com/ircv3/ircv3-specifications/pull/304
In Tell HN: Slack decides to close down IRC and XMPP gatewaysThe working group seems to have formed in 2012, first under Atheme. They do want to work with IETF: https://github.com/kaniini/ircv3-harmony https://github.com/ircv3/ircv3-specifications/issues/132
In IRC v3> The two biggest missing features are persistence and search.
At very least for the persistence part, there is a proposal to add CHATHISTORY batch type[1] to IRCv3 which should allow the server to replay chat history on join (or on request). Search is something else that probably need a little bit more work (especially for a server-side search), though.
[1]: https://github.com/ircv3/ircv3-specifications/pull/156
In Five Open-Source Slack AlternativesShowing the 15 most recent of 22 sources. Enable JavaScript to search and browse every indexed mention.