Maybe it’s too simple? This comment was part of the “My first impressions of web3” discussion we are having in parallel:
A protocol moves much more slowly than a platform. After 30+ years, email is still unencrypted; meanwhile WhatsApp went from unencrypted to full e2ee in a year. People are still trying to standardize sharing a video reliably over IRC; meanwhile, Slack lets you create custom reaction emoji based on your face.
I don’t want to discount Moxie’s otherwise entirely correct (IMHO) observation here but it’s worth remembering that, like everything else in engineering, this is also a trade-off.
IRC is an open standard, whereas WhatsApp is both a (closed, I think?) standard and a single application. Getting all implementations of an open standard on the same page is indeed difficult and carries out a lot of inertia. Getting the only implementation of a closed standard on the same page is trivial. However, the technical capability to do so immediately also carries the associated risk that it’s not necessarily the page everyone wants to be on. That’s one of the reasons why, when WhatsApp is going to be as dead as Yahoo! Messenger, people are still going to be using IRC. This shouldn’t be taken to mean that IRC is better than either WhatsApp or Slack – just that, for all its simplicity, there are in fact many good reasons why it outlasted many more capable and well-funded platforms, not all of them purely technical and thus not all of them outperformable by means of technical capability.
It’s also worth pointing out that, while Slack lets you create custom reaction emoji based on your face, the standard way to share video reliably over both IRC and Slack is posting a Youtube link. More generally, it has been my experience that, for any given task, a trivial application of a protocol that’s better suited for that task will usually outperform any non-core extensions of a less suitable protocol.
It’s also worth pointing out that, while Slack lets you create custom reaction emoji based on your face, the standard way to share video reliably over both IRC and Slack is posting a Youtube link. More generally, it has been my experience that, for any given task, a trivial application of a protocol that’s better suited for that task will usually outperform any non-core extensions of a less suitable protocol.
I mean, I’m not uploading an entire 10 minute video, but likely something short from my camera. To do so from Slack, I press the button and pick it out of my camera roll. From IRC, I have to upload it somewhere, copy and paste the link, and paste that…
meanwhile, Slack lets you create custom reaction emoji based on your face.
This is exactly why email survived all the IMs du jour that have came and gone. A clear vision of what matters and what the core functionality is as well as the problem which it poses itself to solve. All of which Slack lacks.
This is exactly why email survived all the IMs du jour that have came and gone.
Does this really matter, though? I’ve probably used 10 messaging platforms in the last 25 years, some concurrently for different purposes. They each served their purpose. The transition was, in some cases, a little rocky, but only for a short time. I don’t really think my life would have been meaningfully improved by having used only a single messaging system during that time period.
I’ve probably used 10 messaging platforms in the last 25 years, some concurrently for different purposes
Mostly because all the disruptors bootstrapped their network effect by integration with XMPP and IRC and then dropped it when they had enough market share?
The flipside of Moxie’s (excellent) observation is that the slow-moving protocols are easy to support - so that is where the network effects live. If the world is split between centralised network X and Y (which will refiuse to interoperate with each other) and you can get the core functionality with the (more basic) protocol, then there is a a value to the core protocol (you can speak to X and Y)
There are several components to a messaging system:
A client, that the end-user interacts with.
A server (optionally) that the client communicates with.
A protocol that the client and server use to communicate (or that clients use to communicate with each other in a P2P system).
A service, which runs the server and (often) provides a default client.
In my experience, the overwhelming majority of users conflate all four of these. Even for email, they see something like Hotmail or GMail as a combination of all of these things and the fact that Hotmail and GMail can communicate with each other is an extra and they have no idea that it works because email is a standard protocol. The fact that WhatsApp doesn’t let you communicate with any other chat service doesn’t surprise them because they see the app as the whole system. The fact that there’s a protocol, talking to a server, operated by a service provider, just isn’t part of their mental model of the system.
I read a paper a couple of years ago that was looking at what users thought end-to-end encryption meant. It asked users to draw diagrams of how they thought things like email and WhatsApp worked and it pretty much coincided with my prior belief: there’s an app and there’s some magic, and that’s as far as most users go in their mental models.
…then there is a a value to the core protocol (you can speak to X and Y)
But if those two apps won’t talk to one another, why would they speak the shared protocol? Plus, most people don’t choose protocols, they choose applications, and most people don’t choose based on “core functionality”, they choose based on differentiated features. I’m not unsympathetic here, I kicked and screamed about switching from Hipchat to Slack (until Hipchat ceased to exist, of course), but I watched people demand the features that Slack offered (threaded conversations, primarily). They didn’t care about being able to choose their clients, or federation, or being at the mercy of a single company. They cared about the day-to-day user experience.
eh, I think it’s potentially more that email is so deeply embedded into society that it’s difficult to remove, rather than about any defining characteristics of the protocol itself :p
I’m still not sure though if you can call it “survived” when the lowest common denominator for email is still
no dmarc
no SPF
MS blackholes at random(status code ok, mail gone, support can “upgrade” your IP; then you get at least a “denied”, and then you’re told to subscribe to some trust-service for email delivery)
google doesn’t like you sometimes
german telekom doesn’t trust new IPs, wants an imprint to whitelist, no SPF
there’s some random blacklist out there marking IPV4s as “dynamic” since 2002, give them money to change that (no imprint)
and if you want push notification the content goes through your mobile OS provider in plaintext
if you want SMTP/IMAP there is no second factor login at all, so you’re probably using the same credentials that everything else uses
etc
So everyone goes to AWS for a mail sling or some other service. Because the anti-spam / trust model is inherently broken and centralized.
Yes email is still alive and I wouldn’t want to exchange it with some proprietary messenger, but it’s increasingly hard to even remotely self host this or even let some company host this for you that isn’t one of the big 5 (because one bad customer in the IP range and you’re out) - except if you don’t actually care if your emails can be received or send.
It is. To properly use IRC, you don’t just need IRC, you need a load of ad-hoc things on top. For example, IRC has no authentication at all. Most IRC servers run a bot called NickServ. It runs as an operator and if you want to have a persistent identity then you register it by sending this bot the username and a password. The bot then kicks anyone off the service if they try to use your username but don’t first notify the bot with your password. This is nice in some ways because it means that a client that is incredibly simple can still support these things by having the user send the messages directly. This is not very user friendly. There’s no command vocabulary and no generalised discovery mechanism, there’s just an ad-hoc set of extensions that you either support individually or you punt to the user. This also means that you’re limited to plain text for the core protocol. Back in the ’90s, Internet Explorer came with a thing called MS Comic Chat, which provided a UI that looked like a comic on top of IRC. Every other user saw some line noise in your messages because it just put the state of the graphics inline in the message. If IRC were slightly less simple then this could have been embedded as out-of-band data and users of other IRC clients could have silently ignored it or chosen to support it.
I’m still a bit sad that SILC never caught on. SILC is basically modernised IRC. It had quite a nice permissively licensed client library implementation and I wrote a SILC bot back when it looked like it might be a thing that took over from IRC (2005ish?). It was basically dead by around 2015 though. It had quite a nice identity model: usernames were not unique but public keys were and clients could tell you if the David that you’re talking to today was the same as the one you were talking to yesterday (or even tell you if the person decided to change nicknames but kept their identity).
SASL is a thing now. And clients can get by being simple by simply letting the user enter IRC commands directly.
Nickserv is bad mainly because it is an in-band communications mechanism; that has security implications. I have seen people send e.g. ‘msg nickserv identify hunter2’ to a public channel (mistakenly omitting the leading ‘/’).
About every client and almost every network (the only notable exceptions are: OFTC/Undernet/EFnet/IRCnet) support both.
If IRC were slightly less simple then this could have been embedded as out-of-band data and users of other IRC clients could have silently ignored it or chosen to support it.
It’s just really, really easy to throw that kind of stuff together. The only dependency is “you have to be able to open a socket” and that’s it.
I think we’ve got a kind of blindness to the complexity of the enormous pile of dependencies you carry around with you everywhere you go, so when you finally reach a place where you can get something done without it, it’s as if a huge weight was taken off your shoulders.
I vividly remember the simplicity of IRC in my attempts to write an IRC client lib for my own bot. The length of your message is fixed but the size of each field is variable so you if you want to split the client’s input into multiple messages there’s no real good way to abstract it. After a connection hiccup or netsplit or such sometimes the server would just stop talking to my client and I never figured out why. Trying to send files or other Interesting data was so flaky and unreliable and implementation-dependent that you’re best off just not trying. And trying to actually run a server, let alone a network of servers, is also basically entirely implementation-dependent and relies on a small plethora of boutique bots and offline utilities to handle standard administrative functions.
XMPP is like the opposite extreme of badness, but at least I can run Prosody and it basically Just Works to talk to anyone in the world. Even if getting encryption to function is a similarly hair-tearing experience.
Maybe it’s too simple? This comment was part of the “My first impressions of web3” discussion we are having in parallel:
I don’t want to discount Moxie’s otherwise entirely correct (IMHO) observation here but it’s worth remembering that, like everything else in engineering, this is also a trade-off.
IRC is an open standard, whereas WhatsApp is both a (closed, I think?) standard and a single application. Getting all implementations of an open standard on the same page is indeed difficult and carries out a lot of inertia. Getting the only implementation of a closed standard on the same page is trivial. However, the technical capability to do so immediately also carries the associated risk that it’s not necessarily the page everyone wants to be on. That’s one of the reasons why, when WhatsApp is going to be as dead as Yahoo! Messenger, people are still going to be using IRC. This shouldn’t be taken to mean that IRC is better than either WhatsApp or Slack – just that, for all its simplicity, there are in fact many good reasons why it outlasted many more capable and well-funded platforms, not all of them purely technical and thus not all of them outperformable by means of technical capability.
It’s also worth pointing out that, while Slack lets you create custom reaction emoji based on your face, the standard way to share video reliably over both IRC and Slack is posting a Youtube link. More generally, it has been my experience that, for any given task, a trivial application of a protocol that’s better suited for that task will usually outperform any non-core extensions of a less suitable protocol.
I mean, I’m not uploading an entire 10 minute video, but likely something short from my camera. To do so from Slack, I press the button and pick it out of my camera roll. From IRC, I have to upload it somewhere, copy and paste the link, and paste that…
Fair point, that’s not the kind of video I was thinking of. You’re right!
The simplest way for me to share pics among my friends on IRC is to upload the images to our Discord, then share the image from there. Sad, but true.
A big thing hobbling IRC is the lack of decent mobile support without paid services (IRCloud) or using a bouncer.
This is exactly why email survived all the IMs du jour that have came and gone. A clear vision of what matters and what the core functionality is as well as the problem which it poses itself to solve. All of which Slack lacks.
Does this really matter, though? I’ve probably used 10 messaging platforms in the last 25 years, some concurrently for different purposes. They each served their purpose. The transition was, in some cases, a little rocky, but only for a short time. I don’t really think my life would have been meaningfully improved by having used only a single messaging system during that time period.
Mostly because all the disruptors bootstrapped their network effect by integration with XMPP and IRC and then dropped it when they had enough market share?
The flipside of Moxie’s (excellent) observation is that the slow-moving protocols are easy to support - so that is where the network effects live. If the world is split between centralised network X and Y (which will refiuse to interoperate with each other) and you can get the core functionality with the (more basic) protocol, then there is a a value to the core protocol (you can speak to X and Y)
There are several components to a messaging system:
In my experience, the overwhelming majority of users conflate all four of these. Even for email, they see something like Hotmail or GMail as a combination of all of these things and the fact that Hotmail and GMail can communicate with each other is an extra and they have no idea that it works because email is a standard protocol. The fact that WhatsApp doesn’t let you communicate with any other chat service doesn’t surprise them because they see the app as the whole system. The fact that there’s a protocol, talking to a server, operated by a service provider, just isn’t part of their mental model of the system.
I read a paper a couple of years ago that was looking at what users thought end-to-end encryption meant. It asked users to draw diagrams of how they thought things like email and WhatsApp worked and it pretty much coincided with my prior belief: there’s an app and there’s some magic, and that’s as far as most users go in their mental models.
But if those two apps won’t talk to one another, why would they speak the shared protocol? Plus, most people don’t choose protocols, they choose applications, and most people don’t choose based on “core functionality”, they choose based on differentiated features. I’m not unsympathetic here, I kicked and screamed about switching from Hipchat to Slack (until Hipchat ceased to exist, of course), but I watched people demand the features that Slack offered (threaded conversations, primarily). They didn’t care about being able to choose their clients, or federation, or being at the mercy of a single company. They cared about the day-to-day user experience.
eh, I think it’s potentially more that email is so deeply embedded into society that it’s difficult to remove, rather than about any defining characteristics of the protocol itself :p
I’m still not sure though if you can call it “survived” when the lowest common denominator for email is still
So everyone goes to AWS for a mail sling or some other service. Because the anti-spam / trust model is inherently broken and centralized. Yes email is still alive and I wouldn’t want to exchange it with some proprietary messenger, but it’s increasingly hard to even remotely self host this or even let some company host this for you that isn’t one of the big 5 (because one bad customer in the IP range and you’re out) - except if you don’t actually care if your emails can be received or send.
It is. To properly use IRC, you don’t just need IRC, you need a load of ad-hoc things on top. For example, IRC has no authentication at all. Most IRC servers run a bot called NickServ. It runs as an operator and if you want to have a persistent identity then you register it by sending this bot the username and a password. The bot then kicks anyone off the service if they try to use your username but don’t first notify the bot with your password. This is nice in some ways because it means that a client that is incredibly simple can still support these things by having the user send the messages directly. This is not very user friendly. There’s no command vocabulary and no generalised discovery mechanism, there’s just an ad-hoc set of extensions that you either support individually or you punt to the user. This also means that you’re limited to plain text for the core protocol. Back in the ’90s, Internet Explorer came with a thing called MS Comic Chat, which provided a UI that looked like a comic on top of IRC. Every other user saw some line noise in your messages because it just put the state of the graphics inline in the message. If IRC were slightly less simple then this could have been embedded as out-of-band data and users of other IRC clients could have silently ignored it or chosen to support it.
I’m still a bit sad that SILC never caught on. SILC is basically modernised IRC. It had quite a nice permissively licensed client library implementation and I wrote a SILC bot back when it looked like it might be a thing that took over from IRC (2005ish?). It was basically dead by around 2015 though. It had quite a nice identity model: usernames were not unique but public keys were and clients could tell you if the David that you’re talking to today was the same as the one you were talking to yesterday (or even tell you if the person decided to change nicknames but kept their identity).
SASL is a thing now. And clients can get by being simple by simply letting the user enter IRC commands directly.
Nickserv is bad mainly because it is an in-band communications mechanism; that has security implications. I have seen people send e.g. ‘msg nickserv identify hunter2’ to a public channel (mistakenly omitting the leading ‘/’).
There is. https://ircv3.net/specs/extensions/capability-negotiation https://ircv3.net/specs/extensions/sasl-3.1
About every client and almost every network (the only notable exceptions are: OFTC/Undernet/EFnet/IRCnet) support both.
Today it could be done cleanly on many networks, thanks to https://ircv3.net/specs/extensions/message-tags
It still is!
I was grumbling about how my CI provider didn’t support sending notifications over IRC, and then I realized it’d be like 15 lines to do it myself: https://git.sr.ht/~technomancy/fennel/tree/main/item/test/irc.lua
I’m also running an IRC bot that controls my room’s LED lighting on an esp8266 which has 80kb of RAM: https://git.sr.ht/~technomancy/pengbot/tree/micropeng/item/micropeng.fnl#L57
It’s just really, really easy to throw that kind of stuff together. The only dependency is “you have to be able to open a socket” and that’s it.
I think we’ve got a kind of blindness to the complexity of the enormous pile of dependencies you carry around with you everywhere you go, so when you finally reach a place where you can get something done without it, it’s as if a huge weight was taken off your shoulders.
I vividly remember the simplicity of IRC in my attempts to write an IRC client lib for my own bot. The length of your message is fixed but the size of each field is variable so you if you want to split the client’s input into multiple messages there’s no real good way to abstract it. After a connection hiccup or netsplit or such sometimes the server would just stop talking to my client and I never figured out why. Trying to send files or other Interesting data was so flaky and unreliable and implementation-dependent that you’re best off just not trying. And trying to actually run a server, let alone a network of servers, is also basically entirely implementation-dependent and relies on a small plethora of boutique bots and offline utilities to handle standard administrative functions.
XMPP is like the opposite extreme of badness, but at least I can run Prosody and it basically Just Works to talk to anyone in the world. Even if getting encryption to function is a similarly hair-tearing experience.