5 ms·

IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and t

IRC is just a well-established and battle-tested server/client protocol. I'm eager for the day when a competing open source server/client protocol emerges and takes over. I imagine all it would take is a really good reference implementation server and client that everyone can just start using, right?

ChuckMcM 11y ago
I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.
- scrollaway 11y ago
  IRCv3, which I linked, is what you want. It builds atop the IRC protocol to extend it. It is backed by various servers and clients alike. http://ircv3.net/ http://ircv3.net/ They need help, go check them out.
- chei0aiV 11y ago
  There is also RobustIRC which does away with netsplits: https://robustirc.net/ https://robustirc.net/
- e12e 11y ago
  From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix: http://www.matrix.org/ There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers: https://github.com/zulip/zulip Finnaly there's https://tox.chat https://tox.chat -- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing: https://wiki.tox.chat/users/faq#what_is_tox For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough. I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side). [ed: Matrix also have some support through bots/plugins for IRC bridging: https://github.com/matrix-org/matrix-appservice-irc https://github.com/matrix-org/matrix-appservice-irc ]
  - Arathorn 11y ago
    Actually, bridging is actually a first class citizen in Matrix - it's why the project's called Matrix (as we want to go federate/matrix together all the existing silos out there). Current bridges include: * IRC (https://github.com/matrix-org/matrix-appservice-irc https://github.com/matrix-org/matrix-appservice-irc) * Slack (https://github.com/matrix-org/matrix-appservice-slack https://github.com/matrix-org/matrix-appservice-slack) * Verto (https://github.com/matrix-org/matrix-appservice-verto https://github.com/matrix-org/matrix-appservice-verto) (for talking VoIP with FreeSWITCHes) * Respoke (https://github.com/matrix-org/matrix-appservice-respoke https://github.com/matrix-org/matrix-appservice-respoke) (for talking VoIP with Asterisks) * Purple (https://github.com/matrix-org/node-purple/tree/master/appservice https://github.com/matrix-org/node-purple/tree/master/appser...) (for talking through to Skype, Facebook, XMPP, ICQ, AIM... and anything else that libpurple supports) ...and a whole bunch of 3rd party ones too like https://github.com/SkaveRat/xmpptrix https://github.com/SkaveRat/xmpptrix. Some of these are pretty beta, but they're all headed in the right direction. The IRC and Slack ones are the most mature. Glad to hear that you think we are on the right track! [Disclaimer; i work on Matrix]
CamperBob2 11y ago
IRC is just a well-established and battle-tested server/client protocol. Every time it loses another user to a proprietary platform, it loses another battle. Is that what "battle-tested" means?
- dman 11y ago
  IRC lacks a viable attached business model. In fact the act of writing robust services that empower users with data portability and privacy does not appear to have a sustainable model at all currently. I don't know if the current situation is a transitory phase or if this is how large systems will be built in perpetuity.
- sdegutis 11y ago
  By "battle-tested" I meant it has lots of patches/updates to the protocol to protect against certain kinds of attacks. Any new protocol would have to go through the same "battle-testing" before it would be reliable enough.
tptacek 11y ago
It's a well-established shitty protocol, largely designed in the early 1990s as the simplest thing that could possibly work for the workloads we had in the early 1990s. It's terribly limited (7 bit, small message sizes, virtually no useful metadata) and in the 98% use case, its "distributed" characteristics cause more problems than they solve. No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.
- kbuck 11y ago
  Mostly correct, but one nit to pick: IRC is not 7-bit; you can actually transmit unicode messages on every IRC network I've ever seen. It's also not usually unicode-aware, though, so if you send a message too long, it might get truncated halfway through a codepoint. Many IRC networks prohibit non-ASCII channel names and nicknames to prevent impersonation (e.g. with zero-width spaces). The rest of what you've said is pretty much true.
  - tptacek 11y ago
    IRC messages have CRLF message delimiters (and ASCII space field delimiters) and no quoting mechanism in the protocol. They're delivered over a long-lived synchronized TCP stream. Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah? I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new information for me --- but there's more to being 8-bit clean than simply supporting internationalized character sets.
    - SamReidHughes 11y ago
      Yeah, IRC is generally UTF-8 with some Windows-1252 mixed in.
      - plorkyeran 11y ago
        Shift-JIS is still the most common encoding for Japanese channels (but not being able to embed ODOA isn't an issue there either).

ChuckMcM 11y ago

I certainly think having an open source reference implementation for a 21st century (and by that I mean having features like Slack or Yammer or other popular closed source packages) implementation of a successor to IRC would be the minimum starting point.

scrollaway 11y ago
IRCv3, which I linked, is what you want. It builds atop the IRC protocol to extend it. It is backed by various servers and clients alike. http://ircv3.net/ http://ircv3.net/ They need help, go check them out.
chei0aiV 11y ago
There is also RobustIRC which does away with netsplits: https://robustirc.net/ https://robustirc.net/
e12e 11y ago
From what I've been able to gather, the open project that is most like Slack, but also offers self-host, decentralization is Matrix: http://www.matrix.org/ There's also Zulip, which as far as I can gather, is battle-tested, but does not have a strong story for federated servers, nor a good out-of-box experience for really small servers: https://github.com/zulip/zulip Finnaly there's https://tox.chat https://tox.chat -- which doesn't have a lot of the things IRC/Slack has (it's focused around p2p chat) -- but extensions are planned, for eg. persistent group chat. Perhaps most excitingly "new" of the three, which predictably is both a good and a bad thing: https://wiki.tox.chat/users/faq#what_is_tox For those that "want Slack", but self-hosted, open/free software server -- I think Matrix is the most viable alternative -- if IRC is seen as not good enough. I've not included any XMPP servers, although eg. Prosody should be simple to set up and use -- because, apparently like IRC, it has too many problems for people to actually embrace out-of-the box XMPP for team chat. The fact that most big public services that host XMPP tend to favour anonymity probably has something to do with the fact that getting reliable server-side message logging and off-line messaging is still not as easy as one would expect, for any(?) of the big free XMMP daemons (or indeed support client side). [ed: Matrix also have some support through bots/plugins for IRC bridging: https://github.com/matrix-org/matrix-appservice-irc https://github.com/matrix-org/matrix-appservice-irc ]
- Arathorn 11y ago
  Actually, bridging is actually a first class citizen in Matrix - it's why the project's called Matrix (as we want to go federate/matrix together all the existing silos out there). Current bridges include: * IRC (https://github.com/matrix-org/matrix-appservice-irc https://github.com/matrix-org/matrix-appservice-irc) * Slack (https://github.com/matrix-org/matrix-appservice-slack https://github.com/matrix-org/matrix-appservice-slack) * Verto (https://github.com/matrix-org/matrix-appservice-verto https://github.com/matrix-org/matrix-appservice-verto) (for talking VoIP with FreeSWITCHes) * Respoke (https://github.com/matrix-org/matrix-appservice-respoke https://github.com/matrix-org/matrix-appservice-respoke) (for talking VoIP with Asterisks) * Purple (https://github.com/matrix-org/node-purple/tree/master/appservice https://github.com/matrix-org/node-purple/tree/master/appser...) (for talking through to Skype, Facebook, XMPP, ICQ, AIM... and anything else that libpurple supports) ...and a whole bunch of 3rd party ones too like https://github.com/SkaveRat/xmpptrix https://github.com/SkaveRat/xmpptrix. Some of these are pretty beta, but they're all headed in the right direction. The IRC and Slack ones are the most mature. Glad to hear that you think we are on the right track! [Disclaimer; i work on Matrix]

CamperBob2 11y ago

IRC is just a well-established and battle-tested server/client protocol. Every time it loses another user to a proprietary platform, it loses another battle. Is that what "battle-tested" means?

dman 11y ago
IRC lacks a viable attached business model. In fact the act of writing robust services that empower users with data portability and privacy does not appear to have a sustainable model at all currently. I don't know if the current situation is a transitory phase or if this is how large systems will be built in perpetuity.
sdegutis 11y ago
By "battle-tested" I meant it has lots of patches/updates to the protocol to protect against certain kinds of attacks. Any new protocol would have to go through the same "battle-testing" before it would be reliable enough.

tptacek 11y ago

It's a well-established shitty protocol, largely designed in the early 1990s as the simplest thing that could possibly work for the workloads we had in the early 1990s. It's terribly limited (7 bit, small message sizes, virtually no useful metadata) and in the 98% use case, its "distributed" characteristics cause more problems than they solve. No competent person setting out to design a group communications protocol in 2015 could honestly say they'd use IRC as a starting point.

kbuck 11y ago
Mostly correct, but one nit to pick: IRC is not 7-bit; you can actually transmit unicode messages on every IRC network I've ever seen. It's also not usually unicode-aware, though, so if you send a message too long, it might get truncated halfway through a codepoint. Many IRC networks prohibit non-ASCII channel names and nicknames to prevent impersonation (e.g. with zero-width spaces). The rest of what you've said is pretty much true.
- tptacek 11y ago
  IRC messages have CRLF message delimiters (and ASCII space field delimiters) and no quoting mechanism in the protocol. They're delivered over a long-lived synchronized TCP stream. Does it just happen that no 8-bit sequence people normally want to send on IRC ever manages to collide with 0D:0Ah? I haven't seen unicode messages on IRC channels, but I don't spend much time on IRC anymore, and so this is interesting new information for me --- but there's more to being 8-bit clean than simply supporting internationalized character sets.
  - SamReidHughes 11y ago
    Yeah, IRC is generally UTF-8 with some Windows-1252 mixed in.
    - plorkyeran 11y ago
      Shift-JIS is still the most common encoding for Japanese channels (but not being able to embed ODOA isn't an issue there either).