If I want to automate everyday tasks in a house, where it best to use IRC instead of just web services? I searched in Google and didn't find any term of comparisons.

  • 1
    What makes you think IRC would be a good protocol for this sort of thing?
    – hardillb
    Jun 23, 2018 at 6:56
  • Welcome to the site, be sure to check out the tour and maybe How to Ask to find out more about good Stack Exchange quesitons. You might get answers that a more precisely fitting your question if you elaborate a bit more what you're trying to do.
    – Helmar
    Jun 23, 2018 at 9:34
  • Another thing to think is whether you are handling the device and the front-end software used to interact with the devices yourself? If yes then may be you can go anyway and you have full control of the hardware and the software, but if you are doing the hardware and are going to have some one else do the software or vice-versa they you need to to check if both the systems are compatible and can talk the same protocol for e.g what if the hardware only supports MQTT? then you will be forced to use a MQTT broker on the server too.
    – Subbu
    Aug 4, 2018 at 19:53

5 Answers 5


Neither IRC nor HTTP are really optimised for usage as IoT protocols (though they could, in theory, be used).

What makes a protocol suitable for usage in the Internet of Things?

It's difficult to say something meaningful about a huge class of devices, but many IoT devices are small, power-constrained microcontrollers. In order to reduce resource usage (power, memory, etc.) a good protocol tends to transmit and receive as little data as possible. For example, an MQTT PUBLISH packet can have an overhead of 4 bytes (as well as the topic string and payload)1.

On the other hand, HTTP requests tend to be rather weighty:

Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common

SPDY whitepaper

Much of that is designed for the web, and so there are many unneeded features (a lot of headers used aren't necessarily needed for a basic IoT device).

It's also sometimes useful for the server to be able to push data to its clients. HTTP doesn't support this easily (you would generally poll for information instead); IRC does, being a chat protocol.

Request models

As I hinted at earlier, generally HTTP requests are initiated by the client (i.e. an IoT device) and the server responds with any new information. But if your client is interesting in listening to new information... it just has to keep asking the server. If the message needs to get to the IoT device quickly, you might need to poll every few seconds. This is obviously rather wasteful, especially if you're sending nearly a kilobyte of headers each time. Your little AA battery powering a little IoT device won't last long doing that.

IRC is a little better, being a chat protocol. You can join a channel, essentially subscribing to any notifications from there. But again, you get a lot of junk that you might not need. An IoT device probably isn't interested in the op system, or all the other bells and whistles that IRC has grown to support (such as CTCP and DCC). That just adds complexity, uses more bandwidth, and is a waste of developer time implementing it.

The IoT alternatives

There are various protocols trying to be the "IoT equivalent" of the two models:

1: I'm cheating you a bit here, as there are also overheads owing to using TCP. But IRC, HTTP and MQTT all use TCP, so the overhead caused by TCP is unavoidable by using any of these protocols.


Yes, it is possible. I have done it before, and there are a few (but not many) situations where using IRC is a good idea.

An example deployment I have done many years ago was a monitoring system for an old factory (nothing critical though). Around 30 sensors were installed and deployed across the buildings, and each sensor was simply dumping the data into a dedicated IRC channel. People interested in the output of a specific sensor joined the channel, and had the conversations there, discussing the sensor output values and cases for that.

The main advantage of using IRC there was reuse of existing infrastructure - the whole factory used IRC as internal communication tool, with a two server IRC network setup. Everyone also had an IRC client and knew how to use it. And we were not allowed to set up more servers, so had to deal with what was there.

I have also released the IRC client communication library which could be used for this purpose.

On the other hand, IRC has a number of significant disadvantages comparing to HTTP:

  • It is more complex protocol to implement:

    • It is stateful unlike HTTP which is stateless. This means you need more RAM to keep the state, and you need to keep a persistent TCP connection to the server.
    • It is much less straightforward, the event-based codes are not well documented and implemented differently across different IRC servers. Quite often you simply don't know what would "standard behavior" be.
    • No encryption or proper authentication. People do wrap IRC with SSL though. And there are various authentication hacks (i.e. nickbot), but this is not part of standard.
    • Various hardcoded limitations (for example the maximum message length depends on IRC server and may be different among servers).
  • It is more limited comparing to HTTP:

    • No proper way to transmit binary data, as it is text-based protocol. Requires you to deal with transfer encoding such as UUE or base64.
    • No proper way to transmit large volumes of data (even 100k+) without using DCC, which requires clients to be able to establish a direct connection.

Those limitations are severe enough to make little sense of using IRC, unless - as in my case - you are integrating into the environment which is already IRC-based.


To generalise a little more, IoT has a few general constraints/characteristics which will apply to many but not all use cases:

  • Potentially many endpoints
  • Communicate over an insecure or snoopable transport layer
  • Need to handle deployment and firmware upgrades
  • Often handling valuable/sensitive data
  • Automated messaging, frequently small and rapid payloads
  • Energy sensitive payloads (scavenger or battery powered)

Often there will be application specific factors which drive the choice of protocol, in the case where the IoT /function is an extension to some pre-existing functionality. Often a developer will initially design a product using a familiar protocol, planning to migrate to a more optimal protocol in a later revision (time to market trumps optimal design, especially in an emerging market).

This makes the questions of 'can I use this protocol', and also 'Should I use this protocol' slightly different from 'is this the best protocol for this application' or even 'is the improvement offered by this protocol worth the migration cost.'


Almost two years ago the same idea came to me: IRC is good for IoT as a cloud, it can replace MQTT, you can create your own autonomous IoT network, not depended on integration portals such as IFTT. I propose to think together on this issue and create an OPEN (non-commercial) standard. Here's some more info at this site. (Useful features of the IRC protocol) IRC it is better in those cases when it is necessary to build powerful IoT network, but thus not to spend a lot of resources. IRC the client can be inserted in small controllers such as ESP8266, in TVs, in cameras, other devices, and at the same time build a distributed network of thousands of devices.


A few years ago, we came up with the use of the IRC protocol for communication between IoT devices. We described the concept of the protocol on the irc-iot.org website. Now IRC-IoT is actually an open protocol, which DIY lovers can use.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.