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