As Slack prepares to shut down their IRC gateway, it’s time for us to fully launch our native Slack integration for paid accounts.
We’ve been testing this in the labs for a couple of months so things are pretty stable now. To use our integration make sure you’ve upgraded your account, then open the Add a network screen from the web interface. You’ll see an “Add Slack Workspace” button on the right:
You can also migrate any existing Slack IRC gateway connections to use our integration from the labs page or by choosing the “Upgrade slack integration…” menu item for a connection.
There are a few things you might need to setup in your Slack workspace for this integration to work, more details are available in our FAQ entry.
Here’s a side by side comparison of a workspace in Slack and in IRCCloud:
You should notice our Slack integration is a lot closer to the native Slack experience than the old IRC gateway was. Here’s a list of features we’ve added support for:
- Reply threads and reactions
- Display names
- Custom emoji
- Message attachments
- Message editing
- Typing indicators
- Status messages and emoji
- Slash commands using /slack
- Shared channels
These features are all built using IRCv3 extensions, and our integration functions as a standard IRC server, backed by the Slack real time messaging API.
For now, due to the authentication flow, it’s only available to paid users within our apps, but in future we might open it up to people running their own IRC clients.
Let us know how you get on with this integration, and send us any feedback/bugs/feature requests on Twitter, email or IRC.
Today we’re releasing image avatars, a new feature we’ve been testing in our labs section. They come in 2 flavours, public and private, and look like this:
You’ll need to make sure the “User icons” setting is switched on in Layout & Design to see avatars. There’s also a separate setting to disable image avatars completely.
You can click on an avatar or nickname to see a larger version of it in the context menu. Avatars will also appear at the top of private messages.
A public avatar will work on most IRC networks, using an image tied to your user ID, a bit like a gravatar.
Upload a public avatar from your account settings and it’ll be visible to other IRCCloud users on any server based on your ident/hostmask.
Private avatars are only available on private team servers for now, and you can use a different image for each team.
Choose a team avatar by clicking the user icon next to your nickname in the input box.
Behind the scenes
Private avatars work using an updated version of IRCv3 metadata, a deprecated protocol extension that we’re helping to revisit and restore. Technically, any IRC server or client could support metadata avatars today, they just aren’t widely implemented yet.
We use the metadata framework to set your avatar to an unguessable URL, that won’t be published outside of the team.
If you’re running your own bot on a team server, you can give it an avatar by uploading an image and configuring it to send the following command on connect:
METADATA * SET avatar https://example.com/your-uploaded-avatar.png
Public avatars work differently. They rely on a URL that maps an image to your user ID (the bit in your ident/hostmask that looks like
uid7). We use this to detect other IRCCloud users and check whether they have a public avatar by loading that URL, e.g.
We don’t expect other IRC clients to support public avatars, since they only work for IRCCloud users, but they could if they wanted to. It’s intended as a stop-gap until IRCv3 metadata is more widely adopted, and a way for people to try out and get used to avatars on IRC.
As usual, let us know what you think on Twitter, email or IRC.
As part of our ongoing IRC modernisation work, we’re introducing threaded conversations for team servers today.
Reply threads: collapsed, expanded, and opened in a side pane.
Behind the scenes, this feature uses an IRCv3 message tag, meaning any IRC server could support it in future, but we’re not aware of any in widespread use so far.
By default, reply threads will display in an expanded state, where all messages are visible in the main chat area in their original sequence. On the first message of a thread, a single speech bubble icon appears on the left, while all subsequent replies get double bubbles.
You can click on any of these bubble icons to open up the thread in its own side pane. This lets you follow and reply to a thread independently of any other messages sent to a channel.
You can also collapse threads, leaving only the original message showing in the main chat area, with the reply count and participants summarised underneath. You can click on this summary line to open the thread in a pane as before.
Collapsing threads lets you choose which conversations you want to give your full attention, while filtering out those you’re less interested in. Depending on how your teams and channels use threads, you may want to collapse all threads by default, so we’ve added a per-channel setting you can toggle from the options menu.
Threads can also be expanded and collapsed individually, by using the plus and minus icons that appear on the right when you hover over a threaded message. This is also where you’ll find the reply icon (curling arrow), which lets you start a new thread.
Another feature seen here is the reaction icon (smiley face), which lets you choose an emoji to attach to a message. It’s a nice way to give quick feedback on a message. We released emoji reactions on team servers at the end of last year, but never blogged about them. They’re another feature built with message tags.
We looked at a lot of different message threading approaches in other chat services while designing IRC replies, and we’ve tried to create useful, familiar interactions, while avoiding common implementation weaknesses. But we recognise this is new territory for IRC, so we’ll be paying close attention to feedback as people experiment and come up with new ways to use threads.
As always, you can tweet, email or find us on IRC to share your thoughts.
We also hope to see more servers supporting these features in future; we think they have a lot of potential to make IRC more manageable for communities and teams alike.
Today Cloudflare, one of our infrastructure
providers, revealed that they were subject to a security
which may have resulted in some private IRCCloud data, including
passwords and chat history, being leaked between September 2016 and
No payment details were affected.
We understand the chances of any information being compromised
are very low, but we take these issues very seriously indeed. We are
immediately requiring all users to re-authenticate when they next load
IRCCloud. We’re sorry for the inconvenience this will cause.
We recommend that all IRCCloud users change their account passwords,
and we are reviewing our security in light of this issue.
TL;DR: IRCCloud now supports the IRCv3 Strict Transport Security draft.
We’ve always worked hard to ensure secure access to our service. For instance, we’ve enforced HTTPS in our web and mobile apps from day one. We were also early adopters of an HTTP Strict Transport Security (HSTS) policy that adds even stronger safeguards to secure connections, and our policy is now preloaded in all major browsers.
Employing strict security policies for access to our service is important because it protects users who might otherwise be using an untrusted internet connection. But until now, onward connections to IRC networks haven’t enjoyed the same degree of protection.
As mentioned in a previous post, we’re an active participant in the IRCv3 working group. Recently this has involved developing a Strict Transport Security (STS) mechanism for IRC. A first draft specification has now been published, and we’ve just enabled support in IRCCloud.
This means we’ll verify that IRC servers support STS, and always use secure connections with servers that do. Also, if an STS-enabled server fails certificate validation, we’ll refuse to connect and show errors like these:
This is an important change. An invalid certificate can indicate that a secure connection has been compromised and is no longer secure. Previously, if you chose the “Secure port” option when joining a new network, we made sure to connect using TLS/SSL, but we wouldn’t inform you if any certificate errors are encountered. For servers without STS, we aren’t changing this behaviour straight away.
This decision was made because a significant number of IRC networks are set up to use free, self-signed certificates that can’t be validated. These networks are largely volunteer-run with no budget, but our users still expect to be able to connect to them. If we showed an error message on each of these connections, users would quicky learn to ignore security warnings.
However, that situation is gradually changing. With an increased interest in securing our communication channels, and the emergence of free certificate authorities such as Let’s Encrypt, we’re starting to see more IRC networks switch to validated certificates.
In light of this shift, and along with mandatory certificate validation for servers that use STS, we’ll be looking into ways to better surface certificate errors in future.
In the mean time, the IRCv3 STS specification is still being finalised, and you can keep track of its progress on GitHub.