4 ms·

IRC is often romanticized, but after working with its protocol spec, I found it rather unsavory. Its unstructured message format looks like this: :User1 PR

IRC is often romanticized, but after working with its protocol spec, I found it rather unsavory. Its unstructured message format looks like this: :User1 PRIVMSG User2 :Hello, are you receiving this message? While this might look fine at first glance, the lack of more regular structure caused issues. Some messages are easier to parse than others. Each implementation introduced quirks and variations, creating countless edge cases and hairy parsing code. To be fair, IRC _was_ a product of its time... but s-expressions were invented in the 1950s, so adding more structure and rigor to the messages wasn't out of reach. My memories are from a long time ago so I may be overreacting... perhaps the Ergo authors can comment on their experiences if they are around here! I heard about IRCv3 but I doubt that effort solved most of my main gripes with the protocol. If I were to work on a messaging app today, I'd look elsewhere for inspiration. From a quick search, it seems there's room for a modern and _simple_ protocol for chat, simpler than XMPP or Matrix. Essentially, we need a protocol that is for messaging what Gemini is for HTTP. Stretch: squinting a bit, the NATS client protocol looks close to a starting point for something like that [1]. -- 1: https://docs.nats.io/reference/reference-protocols/nats-protocol https://docs.nats.io/reference/reference-protocols/nats-prot...

Tepix 2y ago
Matrix was invented because XMPP was getting too complex. Are we once again at a point where it's time to start over? A federated asynchronous group chat protocol with modern e2e encryption for desktop and mobile use (thus, not always online) is impossible to build without a faire share of complicated corner cases.
- Gormo 2y ago
  > Are we once again at a point where it's time to start over? Ask Sisyphus. In the meantime, while everything else keeps going through newer iterations of XKCD 927 (https://xkcd.com/927/ https://xkcd.com/927/), IRC keeps chugging along, and gaining new features and functionality as it enters its fourth decade despite the previous commenter's gripes.
  - hnarn 2y ago
    > Ask Sisyphus. that doesn't make any sense.
    - Gormo 2y ago
      What doesn't make sense about it?
- emmanueloga_ 2y ago
  I guess I did not make the scope of the project clear. Both Matrix and XMPP specs add up to 100s of pages, 500 or so give or take. IRCv3 seems to be over 100 pages too. In comparison, Gemini is about 10 pages long or so. A bunch of people here talk about setting up a small server for family and friends, so I think a smaller protocol, akin to Gemini in size, could be a lot of fun to work with for small scale deployments.
  - MattJ100 2y ago
    The protocol isn't really an issue for the use-case you talk about. I founded the Snikket project, which aims squarely at the family-and-friends use case you mention (after all, it was made to scratch my own itch - my family's excessive use of WhatsApp for communicating with each other). I can tell you that my family don't care a bit whether Snikket uses IRC, XMPP or Matrix or some real-time Gemini equivalent. There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python). So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features). There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.
    - linsomniac 2y ago
      TIL: https://snikket.org/ https://snikket.org/
    - imiric 2y ago
- ezst 2y ago
  To me, it's slowly become obvious that Matrix was invented because certain people wanted to ride the trendy wave of VC money propping up Slack and friends back in those days. Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up. The fact that they were spreading FUD and disinformation against XMPP and the alternatives in their early days should have been a red herring. The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. The fact that after so long, due to the sheer complexity of it, only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries. I think that we are due for an XMPP resurgence. Not that it is perfect by any stretch of mind, but it is no-BS, mature, lightweight on resources and bandwidth and verifiably fit for purpose, whether you want to host small-scale for your family & friends, or for the whole world with the ambition to be the next GTalk, facebook messenger, or whatsapp (all of them XMPP services at one point or another of their histories)
  - zaik 2y ago
    > red herring I think you meant to say red flag, not red herring: https://en.wikipedia.org/wiki/Red_herring https://en.wikipedia.org/wiki/Red_herring
    - ezst 2y ago
      Oh, TIL! Thanks :-)
  - tcfhgj 2y ago
    > Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up. I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings. > The fact that they were spreading FUD and disinformation against XMPP In the past, I have experienced it more often vice versa than this way. > The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. There are already pretty large deployments (1+ million users), so I think it's scalable to mid-level deployments. > only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries. idk what you mean > all of them XMPP services at one point or another of their histories histories is an important keyword
donatj 2y ago
I see nothing wrong with that syntax? Just avoid the extensions. All you really need to do is get text from A to B and it's great for that.
beepbooptheory 2y ago
Perhaps I'm just a bit dim but I don't really understand the problem here. If that had commas and { ... } around itself no one would give a second thought. But you also mention s-expressions, and there you dont even have to add the commas!
samatman 2y ago
Without unconditionally endorsing the content of this blog (especially the more recent parts of it) you may find this post interesting: http://www.loper-os.org/?p=4003 http://www.loper-os.org/?p=4003
indrora 2y ago
IRC is a Very Old Protocol, you're right. if you dig through the spec you will find a few historic relics: 7-bit ASCII only, 254 character max total line length (some reserved for the message itself), and many many more. NATS as an IRC replacement is using the wrong tool for the wrong job. I've long been thinking about how I'd replace IRC and I keep coming back to another IRC-era protocol that wasn't as popular but was definitely ahead of its time by some amount: Hotline. It wasn't Open like IRC and was limited to Macintosh users for a long time, but it has a lot of what most people are looking for in a "chat system" today. One thing, however, that I think would benefit the protocol designers of the future: Learn from MSN. MSN separated their Authentication and Chat systems. You ask for a token that identifies you to the chat system from the authentication system. These were two separated protocols that did one thing specifically for each other. I honestly think that separating chat-locus and identity from one another is important.
toast0 2y ago
Something a little more tightened up might be nice, because who likes scanning for line endings, when you could have a byte count, and what's up with the colons, and while you're there, might as well have a single byte command, right? But preferably without having seven layers of byte counts, like TLS. But from my recollection of writing bad IRC client in the 90s (including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997), the protocol isn't that hard to work with. Once you figured out you needed to send a : in front of your message text, I don't remember any other big gotchas. It's not XML, and I don't remember any quoting issues, but maybe there's some I forgot. CTCP maybe isn't ideal either. DCC probably doesn't work anymore, but it was a different time when being on the internet meant an expectation that you were a peer and could accept inbound connections.
- averageRoyalty 2y ago
  > including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997 You could write your own servers and services too :). My mIRC scripts all had s:lines on my network, all running in my mIRC (NoNameScript) environment, which I'm sure were on Hawkee somewhere.
stonogo 2y ago
Nobody in the 80s wanted to pay the overhead of s-exprs when a couple of colons did the job. Bandwidth and memory were limited.
- 59nadir 2y ago
  Meh, a binary protocol would've been more efficient in every way, I don't think they really prioritized efficiency. It would've also been simpler for implementers, but there was a time when people thought text-based protocols were good for some reason. They're usually not, and getting the supposed "benefit" of the protocol being human-readable at a glance is trivial to do by just having a code path that turns the binary one into a human-readable one, in whatever shape you want, so you don't have to make your base protocol shitty just because you want human-readability. Complaining about IRC in 2024 is bleh, by the way. The protocol is what it is, you've had a long time to get over it and if you were late to the party you need to realize that yes, there are tons of old protocols that are pretty badly designed, welcome to the world. IRC as a way of public chatting (and maybe even more so running a closed chat) is still somehow among the best we have and personally I'd prefer it if Slack, Microsoft Teams and Discord died completely for "Hey, we've set up a place to talk about this work/event/hobby thing!".

Tepix 2y ago

Matrix was invented because XMPP was getting too complex. Are we once again at a point where it's time to start over? A federated asynchronous group chat protocol with modern e2e encryption for desktop and mobile use (thus, not always online) is impossible to build without a faire share of complicated corner cases.

Gormo 2y ago
> Are we once again at a point where it's time to start over? Ask Sisyphus. In the meantime, while everything else keeps going through newer iterations of XKCD 927 (https://xkcd.com/927/ https://xkcd.com/927/), IRC keeps chugging along, and gaining new features and functionality as it enters its fourth decade despite the previous commenter's gripes.
- hnarn 2y ago
  > Ask Sisyphus. that doesn't make any sense.
  - Gormo 2y ago
    What doesn't make sense about it?
emmanueloga_ 2y ago
I guess I did not make the scope of the project clear. Both Matrix and XMPP specs add up to 100s of pages, 500 or so give or take. IRCv3 seems to be over 100 pages too. In comparison, Gemini is about 10 pages long or so. A bunch of people here talk about setting up a small server for family and friends, so I think a smaller protocol, akin to Gemini in size, could be a lot of fun to work with for small scale deployments.
- MattJ100 2y ago
  The protocol isn't really an issue for the use-case you talk about. I founded the Snikket project, which aims squarely at the family-and-friends use case you mention (after all, it was made to scratch my own itch - my family's excessive use of WhatsApp for communicating with each other). I can tell you that my family don't care a bit whether Snikket uses IRC, XMPP or Matrix or some real-time Gemini equivalent. There may be some scalability differences between different protocols/implementations for the admin of the service, but Snikket fits comfortably on even low-end Raspberry Pi devices, and literally over half of the typical resource usage is by the web dashboard (yay Python). So what difference does the protocol make? It can make a difference to the developer experience. If all you want to do is exchange text messages, then yeah, XMPP and Matrix are absolutely overkill. But - especially for a family-and-friends use case - people also want file sharing, audio/video calls, and all that stuff. It very quickly gets quite complex to support all this stuff, especially in a way that allows you to evolve the protocol over time (trust me, what you think of as core messaging features today, were not a thing 10+ years ago, and messaging in 10+ years will also involve a new set of features). There will always be a set of users for whom plain text messaging is enough (90% of my own daily communication is via messaging in a terminal app). However that set does not intersect significantly with the general population, and practically none of my family members would accept such a solution as a replacement for WhatsApp.
  - linsomniac 2y ago
    TIL: https://snikket.org/ https://snikket.org/
  - imiric 2y ago
ezst 2y ago
To me, it's slowly become obvious that Matrix was invented because certain people wanted to ride the trendy wave of VC money propping up Slack and friends back in those days. Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up. The fact that they were spreading FUD and disinformation against XMPP and the alternatives in their early days should have been a red herring. The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. The fact that after so long, due to the sheer complexity of it, only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries. I think that we are due for an XMPP resurgence. Not that it is perfect by any stretch of mind, but it is no-BS, mature, lightweight on resources and bandwidth and verifiably fit for purpose, whether you want to host small-scale for your family & friends, or for the whole world with the ambition to be the next GTalk, facebook messenger, or whatsapp (all of them XMPP services at one point or another of their histories)
- zaik 2y ago
  > red herring I think you meant to say red flag, not red herring: https://en.wikipedia.org/wiki/Red_herring https://en.wikipedia.org/wiki/Red_herring
  - ezst 2y ago
    Oh, TIL! Thanks :-)
- tcfhgj 2y ago
  > Matrix has been all about superlative marketing and over-promises with little substance and theoretical underpinnings to back it up. I don't think so. The underpinnings were there, may it be the concepts for E2EE, P2P, Verification, Bridging, decentralized rooms and conferencing, synchronized history, etc. Not everything is production ready let alone finished with perfect UX, but it doesn't lack theoretical underpinnings. > The fact that they were spreading FUD and disinformation against XMPP In the past, I have experienced it more often vice versa than this way. > The fact that they haven't stabilized their protocol and made it scalable to mid-level deployments after more than a decade should be a reason for pause. There are already pretty large deployments (1+ million users), so I think it's scalable to mid-level deployments. > only one entity has emerged as willing to sink the costs of Matrix should be a reason for worries. idk what you mean > all of them XMPP services at one point or another of their histories histories is an important keyword

donatj 2y ago

I see nothing wrong with that syntax? Just avoid the extensions. All you really need to do is get text from A to B and it's great for that.

beepbooptheory 2y ago

Perhaps I'm just a bit dim but I don't really understand the problem here. If that had commas and { ... } around itself no one would give a second thought. But you also mention s-expressions, and there you dont even have to add the commas!

samatman 2y ago

Without unconditionally endorsing the content of this blog (especially the more recent parts of it) you may find this post interesting: http://www.loper-os.org/?p=4003 http://www.loper-os.org/?p=4003

indrora 2y ago

IRC is a Very Old Protocol, you're right. if you dig through the spec you will find a few historic relics: 7-bit ASCII only, 254 character max total line length (some reserved for the message itself), and many many more. NATS as an IRC replacement is using the wrong tool for the wrong job. I've long been thinking about how I'd replace IRC and I keep coming back to another IRC-era protocol that wasn't as popular but was definitely ahead of its time by some amount: Hotline. It wasn't Open like IRC and was limited to Macintosh users for a long time, but it has a lot of what most people are looking for in a "chat system" today. One thing, however, that I think would benefit the protocol designers of the future: Learn from MSN. MSN separated their Authentication and Chat systems. You ask for a token that identifies you to the chat system from the authentication system. These were two separated protocols that did one thing specifically for each other. I honestly think that separating chat-locus and identity from one another is important.

toast0 2y ago

Something a little more tightened up might be nice, because who likes scanning for line endings, when you could have a byte count, and what's up with the colons, and while you're there, might as well have a single byte command, right? But preferably without having seven layers of byte counts, like TLS. But from my recollection of writing bad IRC client in the 90s (including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997), the protocol isn't that hard to work with. Once you figured out you needed to send a : in front of your message text, I don't remember any other big gotchas. It's not XML, and I don't remember any quoting issues, but maybe there's some I forgot. CTCP maybe isn't ideal either. DCC probably doesn't work anymore, but it was a different time when being on the internet meant an expectation that you were a peer and could accept inbound connections.

averageRoyalty 2y ago
> including in mIRC script after they added support for sockets in the scripting language in mIRC v5.3 released December 1997 You could write your own servers and services too :). My mIRC scripts all had s:lines on my network, all running in my mIRC (NoNameScript) environment, which I'm sure were on Hawkee somewhere.

stonogo 2y ago

Nobody in the 80s wanted to pay the overhead of s-exprs when a couple of colons did the job. Bandwidth and memory were limited.

59nadir 2y ago
Meh, a binary protocol would've been more efficient in every way, I don't think they really prioritized efficiency. It would've also been simpler for implementers, but there was a time when people thought text-based protocols were good for some reason. They're usually not, and getting the supposed "benefit" of the protocol being human-readable at a glance is trivial to do by just having a code path that turns the binary one into a human-readable one, in whatever shape you want, so you don't have to make your base protocol shitty just because you want human-readability. Complaining about IRC in 2024 is bleh, by the way. The protocol is what it is, you've had a long time to get over it and if you were late to the party you need to realize that yes, there are tons of old protocols that are pretty badly designed, welcome to the world. IRC as a way of public chatting (and maybe even more so running a closed chat) is still somehow among the best we have and personally I'd prefer it if Slack, Microsoft Teams and Discord died completely for "Hey, we've set up a place to talk about this work/event/hobby thing!".