[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.

[VonGuard]

I love IRCCloud and am a subscriber. Glad to see someone is actually trying to improve IRC!

[TazeTSchnitzel]

Aren't avatars already supported with the CTCP AVATAR command?

[jwheare2]

Beyond things like ACTION, CTCP is not widely or consistently supported. This is partly because no one is advancing the specification, and partly because it isn't well specified in the first place. Not to mention the syntactic issues with hacking the payload into IRC's 512 byte limit using invisible meta characters. Metadata and message tags (which support an extra 512 bytes of data) are much more suited to this sort of feature, are better specified, and have more backing from client developers.

[ap22213]

This is very cool. Thank you for doing the work.

I hope that someday there's something similar for asynchronous group communication as well as synchronous. Something like Usenet v2.

[Roritharr]

If the interests would have aligned better, Google Wave could have been this. A better protocol that allows mixing of synchronous and asynchronous communication. It's so sad that opportunity wasnt used with more passion and adopted by a larger ecosystem of players.

[benwilber0]

are you guys ever going to have a stable service? i've been on the verge of dumping irccloud multiple times because of the extremely frequent "ddos" attacks that make your service unusable for hours at a time, despite every other IRC client still working just fine with Freenode.

[bgar]

Just run ZNC instead, if the service is unreliable.

[seanp2k2]

I think that at least some of the point of IRCcloud is that you shouldn't need to set up e.g. a bouncer, possibly on a VPS, just to get reliable group chat.