
IRC v3 - bpierre
http://ircv3.net/
======
prawnsalad
There's a lot of neat stuff in IRCv3 to bring IRC up to date, but most
importantly it is standardising a lot of the existing protocol and patching up
some of the existing warts that make pushing IRC difficult - all while being
backwards compatible.

Developing kiwiirc.com over the past few years to cover many different IRC
servers in all different languages and using many different services/auth
services has been a real pain. It won't improve overnight but these IRCv3
extensions making their way into many different IRC server projects are really
helping to smooth things out.

There is currently a re-write of the Kiwi IRC project to experiment and make
use of the entire IRCv3 extension set, along with some other features to make
web based IRC clients just as friendly and modern as people expect from
messaging applications today. This will be a huge boost to the millions of
people using IRC via Kiwi IRC.

IRC is getting interesting again and IRCv3 is up there making a lot of this
possible.

~~~
lovesIRC
I use KiwiIRC each and everyday. It's one of the nicest looking and easiest to
setup web frontend for my hybrid-ircd setup. Sadly it's just a small group of
friends and an OLD eggdrop bot that runs a crusty old megahal.mod as
entertainment. I haven't found anything that runs as well and can create
humerous replies since then. Hopefully the old code will continue to compile
for awhile.

Anyway, I strayed off topic. I too am excited for IRCv3 and the future of IRC.
I love the protocol, and despite it's drawbacks it serves my purpose well.

And thank you for all your work on KiwiIRC. I love the project :)

~~~
stryk
Bit off-topic, but Eggdrop was the very first thing I ever compiled from
source WAY back in the later 1990's. I figured out how to hack together a
(absolutely terrible) TCL script to monitor #fatefiles on EFNet for messages
by certain nicks (a few XDCC bots) and echo them to another private channel.
It was trash but it worked. One of my earliest experiences that I can remember
with any sort of real code. Ahhhh, the good 'ol days.... great times. :-)

~~~
nexxer
Me too! Eggdrop with TCL/TK on Undernet, with fbsql as mysql client.
Rudimentary chatting with the bot and getting it to answer preset commands,
looking up records in the database. It was frustrating, but when it worked it
felt glorious.

------
forgotpwtomain
I second a comment made below regarding
[https://matrix.org/](https://matrix.org/). I've used IRC for years and still
use it almost daily - but come on Mosh + tmux + ec2 just to have permanent
chat history? I seriously can't advocate this crap to anyone in 2016. It's too
little, too late.

~~~
dijit
There's irccloud for that, or if you want to host yourself shout-IRC is really
good.

~~~
pomfpomfpomf3
irccloud keeps going down every time freenode netsplits. It got so bad lately
I actually canceled my subscription and instead set up weechat+glowing bear,
which is not as polished, but it works fairly well on both desktop and mobile.
(And cheaper)

It's also free software and easy to set up so I encourage everybody to check
it out.

~~~
Gruselbauer
Does it still work if you've got WeeChat customised or does it need to be
vanilla? I'd like to keep using it from a shell while on a decent machine, but
would absolutely not mind the option to connect from mobile clients.

~~~
lorenzhs
Dev here. It's completely independent of your config. Indeed many things carry
over to Glowing Bear automatically, such as scripts that modify the lines
(colorize_nicks.py) or create new text buffers (like highmon or grep.py),
filters, triggers, etc.

~~~
Gruselbauer
Did check it out. Absolutely amazing project and if anyone still reads through
this chat, absolutely what a modern IRC experience should be like in my view.
Effortlessly does _a lot_ of the things people on here like about Slack.

I like WeeChat as a client, it's fast and lean and works inside the tmux
session that pretty governs my digital life both private and professionally.
Alas, it's not always accessible. Getting Putty to reliably work with tmuxed
ncurses apps is a nightmare for example, imho.

Glowing Bear solves this brilliantly. It looks great, you get features like
inline display of media and is easily secured with certificates from Let's
Encrypt.

Thank you, devs. This'll make my "newly discovered FOSS projects of the year"
list for sure.

~~~
lorenzhs
Thanks a lot for your kind words :)

------
c3RlcGhlbnI_
My favourite bit is how they skipped adding length negotiation and it is
causing them problems already. See the brief discussion of size limit on
[http://ircv3.net/specs/core/message-
tags-3.2.html](http://ircv3.net/specs/core/message-tags-3.2.html)

Adding tags forced them to increase message length because of how IRC messages
are hilariously limited to 512 bytes in all directions. In the existing
protocol you already have to guess how long your messages are allowed to be
because the server tacks on a prefix to your message before relaying it, which
can require it to truncate characters to fit the modified message into the
length limit. Having some amount of tags tacked on as well would have made it
impossible to guess how much room you had.

Now if they had started with fixing the actual protocol they wouldn't have had
to deal with that. Honestly this feels more like a standard "let's add cool
stuff" push than intelligent stewardship of the protocol. I guess that is kind
of cool too though.

~~~
kuschku
Length negotiation has been discussed for years, but it’s not that easy.

Imagine user A negotiates a length fo 1024 bytes with the server, user B
negotiates a length of 2048 bytes.

User B sends a message via the server to user A.

What happens?

~~~
c3RlcGhlbnI_
No, it isn't easy but that is what makes it the kind of thing that requires
great spec work to accomplish. It would require proposing transitional steps
and monitoring their adoption over a very long timeline.

However reading their site more carefully I suppose their stated goal
technically is to only provide extensions to the protocol.

So the situation you describe already happens, user A has 512 bytes to send to
the server, but the server has 512-prefix_length bytes to send to B. This is a
flaw in the original protocol and the currently accepted solution is to
truncate server-side(what to do is not stated explicitly, though it is implied
that you probably shouldn't wrap messages). But fixing it is probably out of
scope.

~~~
caf
The prefix is discoverable by client A though: it can send a self-message and
thereafter knows the maximum length it can send to any given target.

~~~
lfowles
They will only know the prefix for the server they are connected to. On a
larger network such as Freenode, client B could be connected to another server
with a different prefix length.

~~~
caf
The prefix doesn't involve the server. The prefix that's prepended to your
messages when another server passes them on to a client is ":nick!user@host "
and is the same for all messages that you originate.

(On Freenode and other networks with a similar service, your hostname can be
changed by services, but the client is notified of this and can update its
knowledge about the prefix).

~~~
lfowles
D'oh, you're right! I looked at a non message command to refresh my memory.

------
k__
I used IRC for over 10 years, but after using Slack for 1 it just felt
outdated to me.

Offline messages and simulatnous logins from multiple places are just two
features I was missing in IRC and didn't even know till I had them, haha.

But yeah, IRC networks just worked as message broker and not as databases, so
I never thought about it.

~~~
DiabloD3
I use ZNC, so logging in from multiple places works well.

~~~
agentdrtran
But now you have to run a ZNC server as well - it's a lot more work for a very
simple feature.

~~~
TeMPOraL
It's not "very simple" \- it's just that with Slack, _someone else_ is running
ZNC for you.

Chat apps don't magically "just work" \- either you run your own
infrastructure, or use someone else's.

~~~
CJefferson
Even with IRC you are still using someone else' infrastructure -- unless you
run your own IRC network from scratch of course.

~~~
nucleardog
If you ever want to feel like you're bashing your head against a brick wall
over and over, set up an IRC server with channel/nick services.

------
jwr
I am very glad this is happening. IRC was one of the first applications I
started using on the internet. These days it nearly disappeared because of
closed silos like Facebook, Twitter and Slack. This effort could help bring
back a decentralized service that is not under the control of any single
company.

~~~
Houshalter
That's the sad thing about decentralized services, they follow a standard that
doesn't get updated. Facebook and slack can add new features every month, but
adding a new feature to email or IRC is so difficult.

~~~
uxcn
Okay... I agree adding features to email and IRC are probably not the easiest
things in the world. There are a number of useful features that have been
added to email over time though, and I don't think decentralized control of
the protocol is the bottleneck. Wave might or might not be a good example.

------
qwertyuiop924
I'm not sure if this is the best approach. Matrix might be a better way to go,
at least for some things. If you really want persistent history and persistent
identity, I'm not sure why you bother with IRC at this point: both will always
be second class there. Try XMPP, Matrix, Psyc, or whatever. Just so long as
you can convince your friends to use it...

~~~
caf
On IRC, your "persistent identity" was your user@hostname (and your nick is
ephemeral). That's why the user@hostname is shown when a client joins a
channel, or in WHO or WHOIS - and why bans match on nick!user@host.

This worked great when people were typically using IRC from their login on a
server at their university (and this is also originally why IRC servers used
the 'ident' protocol when you connect - to stop you spoofing other users on
the same shared system).

It stopped being a viable persistent identity for all users when the @hostname
part stopped being persistent - when people started gettting dynamically
assigned addresses on internet connections at home.

~~~
qwertyuiop924
...Exactly.

------
Jizzle
In many ways, the idea of IRC chat has grown significantly beyond the
conventional client. From the ubiquity of chat for productivity in
applications like HipChat to the hugely successful Twitch.tv platform, IRC has
proven to be a viable backbone in these scenarios. It's quite nice then to see
a concerted standardization effort. Hopefully, many of the proprietary
features we might recognize today will be widespread and freely available in
the future.

------
drcross
I run an XMPP server for myself and a few friend and have had no end to the
trouble with it getting OTR or any level of encryption working reliably before
friends lose their interest.

Please, someone, just offer us an open source slack clone that runs off on a
R-pi and has a walk through wizard to enable the 99% of typical install
requirements.

Even as someone who works in the industry, I dont have time to learn the bells
and whistles that running a chat server requires.

~~~
majewsky
Which problems did you run into? I use Prosody as the server (which is brain-
dead simple to set up) and Conversations as the client on my friends' Android
phones. We just add each others as buddies and set "OTR only" with two taps,
and these problems are solved forever.

I do agree though that the user experience for my OTR-enabled messengers is
shit (especially the "first message not encrypted" problem).

------
jbk
That's a great idea.

Maybe also backport some features of Slack, like edition of messages (with a
flag marking it as edited), or a common way to have plugins/extensions, or
tagging links as images.

~~~
daenney
> like edition of messages (with a flag marking it as edited)

This works on Slack but only with their client. Use one of the bridges and you
have no clue what's going on and they have a centralised system for this.
Syncing that somehow across all servers in an IRC network, across netsplits
and everything, is far from simple. You'd also need to do this retroactively
somehow if a client received a message, disconnects, the message is updated
and the client then reconnects, in order to present an accurate history.

> or a common way to have plugins/extensions

IRC already has a way to allow for extensions. Or do you mean client side?

> or tagging links as images

I'm not sure the IRC protocol should care about that at all. It's more up to
the client to detect image links and Glowing Bear for example already does and
can display them inline.

~~~
jbk
> Syncing that somehow across all servers in an IRC network, across netsplits
> and everything, is far from simple.

Yes, it's not simple. But it's not impossible to do. And yes, it might not
work in 100% of cases, after netsplits, but so what?

~~~
daenney
That matters a lot. Inconsistent history is a problem and leads to all kinds
of communication issues and misunderstandings.

You said you agreed on A

No I edited it later to say that I meant I was in favour of B

Oh, I never saw that edit...

~~~
jbk
That's exactly the same on Slack, and people like it.

------
znpy
I know I'll be dowvoted to oblivion but I'll say it anyway...

You advocate for privacy, You advocate for openness, You advocate for
transparency, You advocate for interoperability, You advocate for host-it-
yourself, You advocate for customisability, You advocate for scriptability ...

But then all of a sudden "oh no IRC, not enough colours, geez, running a
bouncer, who wants to do it?"

\-------

I'd design irc-v3 to be bouncer-friendly, and maybe to integrate some
bouncer-y features into IRC servers as well (most IRC servers keep logs
anyway)

~~~
kbuck
> (most IRC servers keep logs anyway)

IRCd developer and network staff member here. Dead wrong. I don't think I've
seen a single IRCd that keeps logs, and doing so would make it much more
expensive to run an IRC network. Additionally, it would be a huge violation of
privacy, and we value our users' privacy. The IRCd only logs server events
(e.g. network-wide bans, server connection/disconnection, use of
administrative tools) and user connections/disconnections (for anti-abuse
purposes).

If network staff have logs of something, it was either because their IRC
client was present in the channel or because someone else gave them logs.

Most of my network's servers hang around 2-3% CPU usage and <5GB disk usage,
and we'd like to keep it that way because we don't want it to cost a lot to
host. We have an average of 1000-2000 users per server.

------
lucb1e
They've been working on this for years and I'm seeing very little of it. And
beyond that, it's missing everything we take for granted nowadays: scrollback,
keeping note of where you were and media sharing.

Yeah media sharing can be done with, what's it called, CTCP? That's just
piping stuff through a short message service, like Twitter or DNS. It doesn't
properly display media either, but it allows for small file transfers.

And of course scrollback can be done with bouncers. But it's not something I
see my mother using. Facebook Messenger is what I see my mother using.

Is there anything new on the website, or it it just being linked again?

~~~
wcummings
The ircv3 server-time extension can be used to implement scrollback
intelligently, there's a ZNC plugin which does this.

------
bborud
I ran an IRCnet server for 15 years or so and when the PSU crapped out I
decided 15 years would be enough.

If I were to give one piece of advice: forget IRC. If you want to make a free,
large scale chat system, just forget you ever saw IRC. There are no solutions
in that neighborhood.

------
rwmj
IRC (current version) works fine for me. The trick is to front it with ZNC or
similar software.

Anyway, why isn't this being done through the IETF?

~~~
op00to
For you. What about the millions of nontechnical people that need an open
communication platform? We use IRC at my employer, and the complexity of
getting a bouncer set up means that for cross time zone teams, most people
miss any conversations that don't happen in their business hours. This has
huge effects on collaboration.

~~~
grubles
"most people miss any conversations that don't happen in their business hours.
This has huge effects on collaboration."

Why don't you send them logs of the conversations?

~~~
op00to
Suddenly it's my job to bring everyone else up to speed on what happened in
their off hours? I have a job to do. Slack and Rocket.Chat (and matrix and
...) both solve that problem and a lot of others without the legacy bullshit
that IRC slops down the road. I'm sick of spending time working around what is
an outdated and inadequate protocol because of momentum in my office.

~~~
grubles
You realize logging IRC and distributing said logs can be completely
automatic, right? Anyone can set that up. It's honestly kind of humorous that
you find this to be such a mountain to climb.

~~~
op00to
Sure. I'll send you logs. Jump onto Slack, and scroll back. Easy.

~~~
grubles
I support open protocols and not proprietary products that make you pay to
simply keep chat history (Slack deletes messages after +10,000 messages). To
be against IRC is to be against e-mail. IRC has been around at least since the
80s.

------
anindha
From
[https://matrix.org/docs/guides/faq.html/](https://matrix.org/docs/guides/faq.html/)

"IRCv3 exists and is addressing some of these issues; this is great news and
we wish them well. It’s almost a contradiction in terms to get competitive
between openly interoperable communication projects - we look forward to
increasing the richness of Matrix<->IRC bridges as the project progresses."

Why not merge the two projects or just focus on one? WebRTC seems to be a
better protocol right now.

------
kodisha
We, small gaming community were using IRC as matchmaking "service" where we
would all add to a queue, and the bot would then create teams based on players
ranking.

That worked quite nice, for ~15 years, and whole community was created, things
worked quite nice, diehard users used BNC and terminals, but lately everyone
is switching to Discord.

Main matchmaking is still on IRC, but other sub-groups migrated to discord
long ago, and that scares me, because no one at the moment knows what will
happen with Discord year or two from now.

------
tete
Apologies for being off topic. I am happy about this story now being on the
front page.

However, I don't really understand how reposts work. I always thought that
URLs are a unique key.

Is this a way to kind of "retry" them? In this case I'd be curious about how
they work.

[https://news.ycombinator.com/item?id=12570201](https://news.ycombinator.com/item?id=12570201)

~~~
Cogito
Essentially, as I understand it, if multiple people submit the same exact URL
in a short period of time, they count as votes on the first submission (this
may well be completely wrong, but that is how I believe it works).

After a period of time, new submissions are their own post, to allow
submissions that did not get visibility have a chance at being seen. This is
also sometimes done manually by the mods if they see something particularly
interesting that was missed (not sure about the last point though again, I
believe it to be true).

------
vesinisa
Interesting development. Apart from the original IRC specification published
in 1993 and revised in 2000 (supposedly the namesake of "IRC v3") there has
been quite little real standardisation work in IRC protocol, with various
clients, servers and platforms each implementing their custom extensions.

~~~
danieloaks
Standardisation is weird in IRC. From what I've seen, most of it that has
happened has been the result of one group implementing their custom
command/extension and then a bunch of other vendors implementing it in the
same way (as well as all the interesting politics behind it all). There's a
surprising amount that's been mostly-standardised over time, and not just from
formal standards groups like the IETF or IRCv3.

Related, I've been working on these sites for a while which I hope can be
useful: [http://defs.ircdocs.horse/](http://defs.ircdocs.horse/)
[http://modern.ircdocs.horse/](http://modern.ircdocs.horse/)

Still, it's been really interesting to get into. It's nice seeing how things
have gone so far and how they're going forward (and digging into the archives
is always fun).

------
unixhero
Unrealircd is imcredible, as far as irc servers go. I ran it with 300
concurrent users at a local LAN and was able to do a lot of excitimg things
like load balancing between servers other cool things, already back in 2001.

------
jfe
Do a substantial number of IRC users actually care that the current version of
IRC lacks the features that IRCv3 proposes, or are we just modernizing because
we want to make writing IRC bots more complicated?

~~~
SaberUK
IRCv3 makes writing software easier not more complicated.

Take the "away-notify" extension for example. Without it you would have to
repeatedly poll a channel with WHO to see if all users in that channel have
marked themselves as away.

------
jrnichols
I wish that there was just a solid way to prevent DDoS attacks and netsplits.
IRC has always been one of my favorite communication mediums.

------
pmarreck
I still use irccloud.com. Fave feature is preserving history so I can drop
right into a conversation.

------
rachelbythebay
It's still a graph with single points of failure throughout, right?

~~~
Senji
An irc network can have several servers. If one goes down if the others are
online you can connect to any one of them and still be ok. A net split will
happen but they tend to resolve fast.

------
singularity2001
same for voice would be nice. webrtc seems to fail as skype replacement (so
far, in our network)

------
tarancato
I don't feel like typing much because it's nap time but IRCv3 is an almost
closed group of friends, mostly znc core developers, who have decided they can
choose what the future of IRC looks like.

They have put lots of pressure on and harassed other developers of clients and
networks, sending them patches and infiltrating their devs if necessary, so
their ideas are actually implemented.

If you complain about those ideas and specs, they'll tell you to refer to
their github issue tracker, but they mostly ignore those who are not part of
that core group I mentioned.

~~~
nenolod
Regarding the IRCv3 group: it's actually worse.

Historically the IRCv3 project originated at Atheme as a project to bring some
extensions to IRC in order to make it more modernized, such as the SASL
binding (IRC Authentication Layer). ZNC guys and Atheme guys did not get along
because political reasons, so they threatened to fork the project. Atheme
decided to spin off the IRCv3 project at that time as it was no longer really
interesting to Atheme anyway (IAL was adopted in basically every IRCd and most
mainstream clients).

While I cannot really comment on the current managerial processes of the
project (as I do not know what internal discussions the technical board has
anymore, if any), the technical board allows people to submit things that they
know will never ever be ratified, without saying what the outcome will be when
it is already known to them, in order to give the _appearance_ that they are
an open project. In fact, advising people to not work on specifications that
mainstream vendors will not adopt is actively discouraged by the working
group, as the image of being open and the appearance of being non-offensive is
more important than discouraging people from wasting their time.

As for charybdis (a widely deployed IRC server): we keep an eye on the IRCv3
group and implement things that we find interesting. There is no commitment
from us to implement future IRCv3 work just because it is an IRCv3
specification.

As for IRC itself: IRC is a wonderful thing, but honestly in 2016 we can do
much better. The backwards compatibility requirement of IRCv3 (which exists
because they do not feel they have enough influence yet) is a serious crutch
that prevents a lot of potential work for fixing design problems with IRC. The
lack of unique identifiers at the client level (other than nickname) makes a
lot of things like nickname ownership painful. The overall concept of IRC is a
powerful one, but the technical foundation is crap. This is why Slack,
gitter.im, etc are kicking IRC's ass right now, and IRCv3 is honestly too
little too late for that fight. These services offer easy integration with any
type of website and the IRCv3 group is too busy talking about bringing HSTS to
IRC. This is a total and complete inversion of priorities verses where they
should be.

~~~
SaberUK
>ZNC guys and Atheme guys did not get along because political reasons, so they
threatened to fork the project.

I do not wish to start an argument over things which are long dead. However, I
think it is important to note that the "political reasons" were that you were
constantly derailing discussions and threatening people.

I can publish all of my IRC logs if anyone wants evidence of this.

------
meira
Is IRC v3 better than XMPP? There are any ircd as good as ejabberd?

------
Iggyhopper
Apps like Discord are the new IRC.

~~~
PostOnce
IRC is a protocol. Discord is a business.

NNTP/usenet is a protocol. Reddit is a business.

Email is a protocol. Facebook is a business.

Protocols don't go bankrupt and close up shop. They'll still be around in 10
years.

Protocols don't magically pull the rug out from under you, dictate how you use
them, or suddenly change features you want and need without you having any
ability to remain on the old system. They don't suddenly up the system
requirements or discontinue support for old clients. I can still email from
any device I ever could, palm pilot, powermac, whatever. Meanwhile your
favorite app is dropping support for Android 4 or whatever 24months after
release. Or app xyz no longer works on a 2 year old iOS.

Protocols are something I can rely on. Businesses fly by night. I'm not going
to start using Discord now and have it be gone this time next year, I've been
using IRC for decades, and I'm going to keep using it. It works perfectly,
everywhere. Especially if I have mosh and a server running my irc client
somewhere else.

------
grizzles
To fix irc, the best thing they could do would be to add first class support
for js and websockets.

~~~
majewsky
I literally can't tell if this is satire.

~~~
grizzles
It's not, but your comment made me smile.

You seem to feel differently. Go ahead, tell me why it shouldn't be the case.

~~~
charonn0
I'm not the person you asked, but I share their opinion because JS and
websockets do not appear to have any obvious relationship or applicability to
IRC.

~~~
grizzles
A reason to do it is because most internet users >99.9% have a web browser.
<0.01% have an irc client. You could argue that Twitter or Slack has sort of
filled this niche for people who want to do #topic based chat but if the goal
is to do it in an open protocol, then that's imo why it would be applicable to
irc.

~~~
majewsky
Okay, but in which way is JS and WebSockets relevant to the IRC core protocol,
if you usually have a proxy (such as KiwiIRC) which speaks IRC in the backend
and HTTP/JS/websockets/whatever in the frontend.

------
nocarrier
Why isn't encryption baked in by default? It's optional from what I can tell.
I don't know how you can design a new protocol and not include encryption.

~~~
daenney
> The IRCv3 Working Group is a collection of IRC client and server software
> authors working to enhance, maintain and standardize the IRC protocol using
> backwards-compatible extensions.

It's not a new protocol.

~~~
nocarrier
Fair enough, but I feel you're being a little pedantic since there are base
extensions described which are required, and optional extensions which are not
required. TLS is one of the optional extensions.

So I'll reframe my question and ask: Why isn't TLS a base extension?

~~~
nocarrier
Hmm, I didn't see the 3.3 spec which is still being developed, it looks like
they are doing strict transport security as a base extension. So that would
address most of my concerns I think. I would still prefer to see TLS required
no matter what.

------
JshWright
I am a long time IRC user (irssi is my 'daily driver'), but I'm pretty sure
IRCv3 is called "Slack".

~~~
vesinisa
Hooray for centralised, proprietary tools controlled by a single corporation!
/s

Seriously though, I think this is exactly what is needed for IRC: a facelift.
IRC is hugely superior to centralised tools like Slack for obvious reasons.
But if people are moving to Slack it's not enough to say they should not do
that, but try to actually offer a competitive user experience.

~~~
uola
I can't say it's bad to update the IRC protocol, but I don't think it would
make much difference either. What people don't realize with "decentralized"
services is that they don't have a good ecosystem anymore. The web stack,
which favors centralization, ships with usable encryption, user interface,
distribution etc. To achieve similar end results with "conventional" stacks
you will spend far more effort with far less developers to choose from.

People tend to dismiss web application development for being careless, but at
the same time forget that this is what made these clear text fairly
rudimentary protocols popular. Until we get encryption built-in, more robust
programming languages and figure out distribution on the desktop it's unlikely
that the ecosystem will come back.

------
paradite
Looking at homepages of various IRC clients, I feel like I am back to 5 years
ago when jQuery UI is still a thing:
[http://ircv3.net/software/clients.html](http://ircv3.net/software/clients.html)

Equally out-of-date are the screenshots of the clients on the homepages. I
don't think I will ever see an IRC desktop or web client that has decent UI
according to today's standard. Then again probably I am too young to be their
target audience.

Edit: Okay there are some IRC clients that actually look good, such as Riot,
but not on the list of IRCv3 client.

~~~
xPaw
Try taking a look at The Lounge, it aims to be rather modern.
[https://thelounge.github.io](https://thelounge.github.io)

~~~
derkha
Nice, this may make me finally move on from irssi

