
IRCv3 - bemmu
https://blog.irccloud.com/ircv3/
======
jwheare2
Hi, I wrote the blog post and run IRCCloud.

To clarify, the changes detailed here are to do with IRC as a low level
protocol. While these enhancements do have user benefit, many of the user
experience improvements we work on aren't necessarily at the protocol level.

For instance, things like file sharing, persistent logging, synced mobile
clients, push notifications etc can all be built as extra infrastructure on
top of the protocol. In the same way that the Slack _protocol_ doesn't give
you file sharing without somewhere to host hose files, IRC as a protocol is
less useful without services built around it. And that's the main benefit to
using a service like IRCCloud.

However, it's worth noting that an important aspect of the IRCv3 effort is
around introducing new data types to the protocol. Things like message tags
and metadata, that will enable client developers to offer new features that
would be hard or impossible to implement without breaking a lot of the
existing ecosystem around IRC. And it's the existing open communities on IRC
that represent a major advantage over closed proprietary chat systems.

Some examples of things that could be achieved with these new data types and
mechanisms:

* If you wanted to add avatars, there isn't a standard place to put it that all clients will know how to access. A metadata key enables that.

* A bot that supports some form of rich payload, e.g. a quoted snippet from a linked website, with a favicon and preview image. You could provide this with message tags.

There are also interesting opportunities with the -notify capabilities. Being
able to receive status updates (e.g. if someone goes away or identifies) lets
clients present useful presence indicators for people you're chatting with.

I can imagine these being combined in interesting ways. For example, label a
message with an id tag and then receive fave-notify messages for it, to allow
a "starring" feature.

For IRC to be a competitor to modern chat alternatives it needs a combination
of these improved protocol features as well as a support infrastructure.

~~~
ryanlol
I'm curious as to how many of the people that actually use IRC want any of
these features? Almost everyone I see is using irssi/weechat.

~~~
untog
Well, I think the argument is to increase the number of people who _do_ use
IRC - I'd say that Slack has proved people want features like that. If
existing IRC users don't want to use the features, they don't have to.

~~~
ryanlol
But seems like this would be fundamentally incompatible with the normal IRC
clients that most people currently use.

jwheare2 keeps talking about the existing irc ecosystem and communities, but I
really doubt any of the big ones would be switching over.

~~~
jwheare2
freenode and most of the runner up biggest networks are on board with IRCv3.
Also, the specs are backwards compatible by design.

~~~
ryanlol
>Also, the specs are backwards compatible by design.

The spec may be, but I doubt any of the examples you gave would ever be
compatible with irssi & co.

~~~
anonbanker
why wouldn't they be? svgalib and directfb allow irssi to display avatars in
full color. You could use libcaca to reduce them down to ascii, if needed.

Either way, the point of an _extension_ is that it degrades gracefully if the
extension is not supported. Users that can see avatars get to see avatars. the
ones that don't care don't lose the rest of the experience.

~~~
ryanlol
>why wouldn't they be? svgalib and directfb allow irssi to display avatars in
full color. You could use libcaca to reduce them down to ascii, if needed.

Yes for both of the people running irssi in a framebuffer console, libcaca
would obviously need ridiculously large avatars.

>Either way, the point of an extension is that it degrades gracefully if the
extension is not supported. Users that can see avatars get to see avatars. the
ones that don't care don't lose the rest of the experience.

Yeah, but the ones that do don't see any avatars either, because they're the
only ones that support it.

------
gtirloni
Couldn't find support for offline messages in the new specs. Is it there
somewhere?

~~~
nextos
I think IRC won't support offline messages as it somehow conflicts with the
whole protocol. You can achieve this with your own setup via ZNC, but then you
need a server running 24x7.

IRC will hopefully stay as the preferred option for technical discussions, but
we will need something else for personal communication (with increased privacy
too).

We have XMPP, which is complex, lacking and has too much client fragmentation.
And emerging things such as Signal, Tox, Ring or Matrix.

It's a challenge to implement offline messages and P2P. Even server federation
is not easy if you want really nice crypto. E.g., see Signal.

~~~
RubyPinch
To give a usecase where tagging/requesting/etc offline messages is useful:
using ZNC.

instead one currently needs to shell into their ZNC box and start grepping
through logs, not pleasant

(there is a backlog module, however it required a bit of silly configuration
and didn't support getting anything other than chat lines)

~~~
jeena
Perhaps I configured it wrongly but when I forget to close my IRC client at
work then ZNC is not buffering and showing me anything on the other clients
when I log in.

~~~
arm
Yep, you would have to change the settings a bit if you want that behaviour.

Connect to your ZNC’s web frontend, and then go to:

ZNC » webadmin » Edit User [ _the name of the user you’re editing_ ] » Edit
Network [ _the name of the network you’re editing_ ]

Then checkmark the following:

• awaystore¹ (Adds auto-away with logging, useful when you use ZNC from
different locations)

• simple_away² (This module will automatically set you away on IRC while you
are disconnected from the bouncer.) _[You probably already have this checked]_

 _(This is assuming you’re on ZNC 1.6.1 like me)._

――――――

¹ — [http://wiki.znc.in/Simple_away](http://wiki.znc.in/Simple_away)

² — [http://wiki.znc.in/Awaystore](http://wiki.znc.in/Awaystore)

------
adulau
What's the current status of SILC[1][2] versus IRCv3?

[1] [https://github.com/silc](https://github.com/silc) [2]
[http://silcnet.org/info.html](http://silcnet.org/info.html)

~~~
sdfjkl
Same as for the last decade or so: Complete, there are some clients/plugins,
nobody uses it.

------
arca_vorago
Its nice to see irc isnt completely forgotten and there arenpeople dedicated
to improving it. It's truly an underrated resource imho.

Anybody else use screen and emacs erc on a vps for irc? One thing I dont like
doing is connecting directly to irc. Also, don't forget about cloaking!

------
blfr
_SASL is an authentication protocol, which improves the way e.g. NickServ
login is performed, allowing connections to be established more quickly._

What is the advantage of using SASL over logging in with a client SSL
certificate?

~~~
jcranmer
SASL is a protocol that allows you to mix several different schemes. You could
(if the server supports it) use GSSAPI (e.g., authenticate using Kerberos or
Active Directory, i.e., the backend for enterprises). You could instead use,
say, EAP. Or you could use OAuth 2. Or you could use SSL certificates. Or you
could forgo any of that and just use CRAM-MD5 or SCRAM-SHA-1 or SCRAM-SHA-256
for regular password authentication. Or, if you're really lazy, you could just
use a plaintext user/password combination.

------
746F7475
First time heard of irccloud today and I was interested since I've been
running cheap-o VPS server mainly for irssi for past few years and this seemed
like good alternative, but with quick testing this isn't a solid product.

First problem I had is the same as every single cloud platform for stuff we
have on desktop already (like cloud IDEs) why can't I customize things? Why
can't I do simple stuff like hide my channel list/tree? I saw someone asked
this feature via Twitter 2 years ago and Irccloud account replied "request
accepted" or something and still nothing.

Second more serious issue is chat history. It simply doesn't transfer from one
device to next. If I have it open in one machine and open it on another the
last instance will lose ALL latest chat history (in my testing at lest 30
minutes worth). This to me breaks the whole concept, you have no product.
Whole point of this service is to provide easy access to the same IRC instance
from anywhere, but if there is no chat history/log it doesn't provide that, it
would be the same if I just joined with another client which I can do for free
from multitude of different web based IRC clients.

It's cool that you try to improve IRC, but first you really should probably
get your product in working order.

~~~
jwheare2
The issue of the missing chat history is actually a rare bug we have at the
moment combined with bad timing.

When we're under heavy load (e.g. Freenode is netsplitting) our cache can get
backed up. The cache is where your logs are served from when you reconnect a
client.

At the moment we don't do a good job of detecting a slow cache and re-
requesting from the primary log storage, but we're working on a fix for that,
as well as improving cache performance so it doesn't get backed up as much.

It just so happened that there was a large split on Freenode earlier today,
around the time you posted this message.

~~~
ryanlol
Your systems have to be seriously fucked up if freenode netsplitting causes
"heavy load" this is super easy to parse text data we're talking about.

Edit: 4 downvotes but nobody interested in explaining why it makes sense for
freenode netsplits to break the entirety of irccloud (which they do,
regularly).

~~~
cmrdporcupine
My guess is you're being downvoted for profanity and negativity, nothing about
technical explanations.

Try rephrasing your question in a way that the parent is more likely to
respond to.

~~~
ryanlol
>My guess is you're being downvoted for profanity and negativity, nothing
about technical explanations.

The negativity is very well deserved, shit code is shit code.

IRCCloud is a service with less than 200k registered users (being optimistic
here, realistically the number is closer to 143578) out of which maybe 10% are
active (that's being super optimistic too) so that brings us to about 20k
users.

With ~20k connected users the service can barely manage to remain operational
when any of the bigger networks experience netsplits, which happens all the
time. IRC networks are constantly getting DDoSd.

If their service can't even deal with normal everyday load, that's a sign of
_serious_ issues.

The only conclusion is that IRCCloud must be very badly implemented and
suffers from serious technical deficiencies, I believe "fucked up" is
appropriate here.

This isn't a daycare, if someone finds "fuck" offensive they should probably
just pull out their ethernet cord.

~~~
viraptor
It's not about the word itself. It's that people here can express their
opinions in better ways typically. Every service has bugs. This is one of
theirs. Whatever software project you create will have bugs. That's the world
we live in.

"fucked up" blames the developers - did you really intend to say they fucked
up, by providing a non-critical service that's very usable almost all the time
and has cache coherency issues occasionally. Missing chat history is not a
serious technical deficiency if it can be simply re-requested. If you really
wanted to rant at them and say their service is fucked up, then downvotes are
deserved.

~~~
ryanlol
>"fucked up" blames the developers - did you really intend to say they fucked
up, by providing a non-critical service that's very usable almost all the time
and has cache coherency issues occasionally. Missing chat history is not a
serious technical deficiency if it can be simply re-requested. If you really
wanted to rant at them and say their service is fucked up, then downvotes are
deserved.

I'm guessing you don't use IRCCloud very much then?

It's not just cache coherency issues, IRCCloud slows to a crawl/stops working
entirely when there's bigger splits.

And when are the developers not to blame? If you write code that doesn't work
it tends to be your fault that it doesn't work, unless of course management
forced you to write bad code.

>If you really wanted to rant at them and say their service is fucked up, then
downvotes are deserved

No, I'm just annoyed by how he completely sidestepped the actual underlying
issues, e.g their service being unable to support their current user counts.

------
jd3
I'm so confused as to whether Mozilla Thunderbird utilizes ChatZilla itself as
the irc backend or if the developers simply re-wrote irc support from the
ground up... ChatZilla is by far my favorite client and I would love if it
could support new IRCv3 features.

------
TazeTSchnitzel
Will these changes eventually make it into a new RFC? IRC is an IETF standard.

~~~
thristian
IRC is kind of an IETF standard. That is, there are RFCs for the IRC protocol
that are a useful introduction, but they don't cover basic user-visible things
like `/me` or formatting codes (colour/bold/etc), and even the non-IETF specs
that cover those things aren't necessarily reliable (the CTCP spec has a whole
thing about how to encode metacharacters in payloads that in practice
everybody ignores).

At least these IRCv3 guys are writing down what they're doing.

~~~
TazeTSchnitzel
There are unofficial extensions, yeah, but that doesn't make IRC not be
standard. I think it just needs to happen that someone gets the various
extensions finally standardised.

------
dfc
Is this an open standard /follow up to RFC2812/2813 or is it a company trying
to coopt an open standard and sell a closed service?

~~~
jwheare2
IRCv3 is a working group consisting of many different IRC developers and
operators
[http://ircv3.net/participation.html](http://ircv3.net/participation.html)
that produces specifications by consensus, and there is a longer term effort
to propose a unified RFC that improves upon 2812/1459.

IRCCloud as a company is an active member of the working group. I'm not sure
how we would be co-opting any standard, but we implement them, and yes, we do
sell a service.

It's closed in the sense that we provide a proprietary API on top of IRC and
you need to sign up to our service to enjoy any benefit from it. But it's open
in the sense that you can connect to any open IRC server, and if you choose to
no longer use our service, you can download your logs, pick up any other
client and continue to use IRC without having to recreate your community from
scratch.

How suspicious you should be of all the above is entirely up to you.

------
x5n1
does irc support encryption?

~~~
notalaser
The problem is stingier than it looks.

On one hand, anything that can run on top of an encrypted connection "supports
encryption". IRC is no exception, IRC servers have had SSL support for a long
time now.

However, the messages you send over the SSL connection will arrive in
plaintext form at clients who chose not to use SSL when connecting to that
server. Logs are also stored plaintext by many clients.

There are servers which no longer allow non-SSL connections to cope with that.

Edit: this debate is pretty long-winded, it was a pretty hot topic in a lot of
circles even 10 years ago. I've heard proposals of adding encryption _on top_
of IRC. The advantage being that even peers over unencrypted connections would
still get encrypted data. I vaguely remember toying with some perl scripts for
doing that over irssi.

It's pretty pointless IMHO. People rely on IRC logs, and IRC in general has
largely been for open forums and open collaboration.

If someone needs to discuss sensible stuff over IRC, it's fair to assume that
they don't want it discussed with anyone who happens to join their channel. In
that case, it's perfectly acceptable to set up an SSL-only server with strong
authentication (or even better, to ensure that you don't leak logs, to have
everyone connect over SSH to a machine that runs a local-only IRC server).

~~~
davb
It's also worth noting that many clients now have LibOTR (Off The Record -
end-to-end encryption) plugins available.

For group chat, the best option seems to be a TLS only server and an agreement
with all parties to avoid publishing logs on sensitive channels. Whatever
technical measures or protocols are in place, you always rely on your
correspondents' cooperation (no logging, no bots, only use secure terminals,
etc).

~~~
notalaser
> For group chat, the best option seems to be a TLS only server and an
> agreement with all parties to avoid publishing logs on sensitive channels.
> Whatever technical measures or protocols are in place, you always rely on
> your correspondents' cooperation (no logging, no bots, only use secure
> terminals, etc).

Exactly, at the end of the day you're still depending on people not to leak
these things anyway.

~~~
laumars
This is the thing that's gets me about encryption on public communication
platforms. On the one hand, I do want my authentication to be secured, but as
much as we might discuss securing chat, it's all posted in the public anyway.
It's like standing on a street corner and shouting your personal details and
hoping that's every stranger adheres to the implied NDA.

At the end of the day, as long as your authentication is secured, then that
keeps your password safe. The fact that your communication to the server is
also secured is a bonus as it means that any eavesdroppers can't tell which
user your are not even which channels you hang out on. But anything more than
that is just pointless given you can't trust all clients to be secure.

I'm not entirely sure this is a problem that can be solved in any way either.
If the text can be read, then it can be ripped and logged. Much like the
Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not
exactly the same, but definitely some overlap)

~~~
HerraBRE
Encryption isn't just about keeping secrets. When correctly deployed it also
prevents tampering; when your comms are insecure, it's quite easy for a MITM
to inject or remove content.

This is not hypothetical, although most of the large-scale attacks of this
nature have focused on the web. What sort of havoc can someone cause in your
organization by injecting fake chat messages? :-)

~~~
laumars
Indeed. However my point wasn't that we shouldn't have TLS connection to the
server, but rather than end-to-end encryption (ie client to client) doesn't
make a whole lot of sense on public channels since the comms are public.

