4 ms·

IRC is free and what Slack is based on. There are plenty of nice clients, and it's easy to write "plugins" you just write for the protocol like a webapp.

philippnagel 9y ago
I wonder why IRC instead of XMPP.
- vidarh 9y ago
  IRC is simplistic and hacked together (no proper spec covering everything) but you can talk the protocol manually via telnet to test things. XMPP is "cleaner" by many measures, and far better specified, but is verbose and complex. Both have large ecosystems of software you can lean on, with different pros and cons. People will have different preferences with respect to which is most suitable to build on.
  - throwaway2016a 9y ago
    > IRC is simplistic and hacked together (no proper spec covering everything) but you can talk the protocol manually via telnet to test things. IRC is actually extremely well defined and documented. There is a whole collection of RFC documents related to it that are very well done. I would say it is at least as carefully specified as HTTP. [1] https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2812 The extension protocols that are built on top of IRC are also well defined. "Simple" here is a function of well thought out design not the opposite. Things that are just thrown together would be a mess compared to IRC. [1] Source: I used those RFCs to developer an IRC client a decade+ ago.
    - vidarh 9y ago
      There is any number of mutually incompatible servers out there, and I don't know of any of them that sticks to just the RFC's. The RFC specifies the wire format and basic messages relatively ok, but most IRC networks also rely on a variety of additional services that are largely unspecified. The RFC you refer to is (one of several - it also includes at least 2810, 2811, 2813) retroactive attempt at untangling the gigantic mess of hack upon hack added by a variety of servers over the years since the original IRC RFC, because nobody relied on just the original RFC any more. See sections 6 and 7 in particular - they did not even try to address the variety of extensions or compatibility beyond the reference implementation, which pretty much nobody used any more by the late 90's. E.g. consider where in the RFC it says something about colour support in messages. It doesn't - that was a proprietary extension added by mIRC [1] that everyone then just adopted. As a result clients that implement the RFC and assumes they'll just get readable text will end up displaying control characters to users, like many clients id for years. These RFC's also don't specify CTCP at all [2] (used for DCC and the like), which leaves you with a woefully incomplete client. Here is another example of servers (EFNet in this case) deviating, by providing it's own timestamping mechanism [3]. The reality is that if you implement the RFCs you're only halfway there for a client, and may not even be able to talk to the network you want if you're writing a server (most networks won't let you use the server of your choice anyway). Client-to-server compatibility is better than server to server compatibility, but still requires a lot more than the RFCs to provide the functionality users expects. It's true that you can mostly deal with this "manually". E.g mIRC colour codes does not require server side changes, and some clients could handle them just with macros, but that's less forethought and clean design and more a matter of the fact that IRC mostly just spews out to users what you pass in, and a whole lot of the reason server-to-server compatibility is so poor is that each major network has done a lot of independent work to work around the various abusive mechanisms people have come up with to take advantage of the woefully underspecified semantics. The result is that, yes, you can handle a lot of services client side because IRC users are used to tolerating clients that show them control codes and the like if another client has added additional functionality that theirs doesn't support. Like mIRC color codes, which means messages includes ASCII 0x03 (^C) followed by colour codes, which will be visible noise on clients that doesn't support it, with no mechanisms for negotiating features. To me that is a massive mess, that still has not been cleaned up, and likely never will be, because all current clients have papered over all the ugly cracks over the years. Source: Written code to interface to IRC on and off since 1994. [1] http://www.mirc.com/colors.html http://www.mirc.com/colors.html [2] Here is EFNets document on CTCP: http://www.efnet.org/?module=docs&doc=8 http://www.efnet.org/?module=docs&doc=8 [3] http://www.efnet.org/?module=docs&doc=19 http://www.efnet.org/?module=docs&doc=19
rcarmo 9y ago
You mean "inspired by". There is an IRC gateway, but Slack does not work atop of IRC.
aidos 9y ago
I used IRC many years ago but hadn't used it for years. I got into it again recently as I've only just discovered that it's a great way to get help with open source bugs. Anyway, I've also discovered that Slack and IRC are very different beasts. And IRCCloud account goes a way to helping to get you closer in terms of the history but it's still not the slack experience. Don't get me wrong, I like them both and I far prefer the flexibility and lightness of IRC, but there's no way you're selling that in to a business that needs something that just works. Ironically, Slack is begging to be hacked for industrial espionage so is a pretty dangerous place to have all your business conversations but you know, it's pretty....
lokedhs 9y ago
We also used to use IRC, but then after realising that we wanted some of the features of Slack (a persistent, searchable log of messages for example), so we went and developed such an application that had all the features we needed. It even has some features that Slack still don't have, even though they have hundreds of developers and we were two guys working on the evenings. We also released it fully open source. https://github.com/cicakhq/potato https://github.com/cicakhq/potato
- deleted 9y ago
  [deleted]

philippnagel 9y ago

I wonder why IRC instead of XMPP.

vidarh 9y ago
IRC is simplistic and hacked together (no proper spec covering everything) but you can talk the protocol manually via telnet to test things. XMPP is "cleaner" by many measures, and far better specified, but is verbose and complex. Both have large ecosystems of software you can lean on, with different pros and cons. People will have different preferences with respect to which is most suitable to build on.
- throwaway2016a 9y ago
  > IRC is simplistic and hacked together (no proper spec covering everything) but you can talk the protocol manually via telnet to test things. IRC is actually extremely well defined and documented. There is a whole collection of RFC documents related to it that are very well done. I would say it is at least as carefully specified as HTTP. [1] https://tools.ietf.org/html/rfc2812 https://tools.ietf.org/html/rfc2812 The extension protocols that are built on top of IRC are also well defined. "Simple" here is a function of well thought out design not the opposite. Things that are just thrown together would be a mess compared to IRC. [1] Source: I used those RFCs to developer an IRC client a decade+ ago.
  - vidarh 9y ago
    There is any number of mutually incompatible servers out there, and I don't know of any of them that sticks to just the RFC's. The RFC specifies the wire format and basic messages relatively ok, but most IRC networks also rely on a variety of additional services that are largely unspecified. The RFC you refer to is (one of several - it also includes at least 2810, 2811, 2813) retroactive attempt at untangling the gigantic mess of hack upon hack added by a variety of servers over the years since the original IRC RFC, because nobody relied on just the original RFC any more. See sections 6 and 7 in particular - they did not even try to address the variety of extensions or compatibility beyond the reference implementation, which pretty much nobody used any more by the late 90's. E.g. consider where in the RFC it says something about colour support in messages. It doesn't - that was a proprietary extension added by mIRC [1] that everyone then just adopted. As a result clients that implement the RFC and assumes they'll just get readable text will end up displaying control characters to users, like many clients id for years. These RFC's also don't specify CTCP at all [2] (used for DCC and the like), which leaves you with a woefully incomplete client. Here is another example of servers (EFNet in this case) deviating, by providing it's own timestamping mechanism [3]. The reality is that if you implement the RFCs you're only halfway there for a client, and may not even be able to talk to the network you want if you're writing a server (most networks won't let you use the server of your choice anyway). Client-to-server compatibility is better than server to server compatibility, but still requires a lot more than the RFCs to provide the functionality users expects. It's true that you can mostly deal with this "manually". E.g mIRC colour codes does not require server side changes, and some clients could handle them just with macros, but that's less forethought and clean design and more a matter of the fact that IRC mostly just spews out to users what you pass in, and a whole lot of the reason server-to-server compatibility is so poor is that each major network has done a lot of independent work to work around the various abusive mechanisms people have come up with to take advantage of the woefully underspecified semantics. The result is that, yes, you can handle a lot of services client side because IRC users are used to tolerating clients that show them control codes and the like if another client has added additional functionality that theirs doesn't support. Like mIRC color codes, which means messages includes ASCII 0x03 (^C) followed by colour codes, which will be visible noise on clients that doesn't support it, with no mechanisms for negotiating features. To me that is a massive mess, that still has not been cleaned up, and likely never will be, because all current clients have papered over all the ugly cracks over the years. Source: Written code to interface to IRC on and off since 1994. [1] http://www.mirc.com/colors.html http://www.mirc.com/colors.html [2] Here is EFNets document on CTCP: http://www.efnet.org/?module=docs&doc=8 http://www.efnet.org/?module=docs&doc=8 [3] http://www.efnet.org/?module=docs&doc=19 http://www.efnet.org/?module=docs&doc=19

rcarmo 9y ago

You mean "inspired by". There is an IRC gateway, but Slack does not work atop of IRC.

aidos 9y ago

I used IRC many years ago but hadn't used it for years. I got into it again recently as I've only just discovered that it's a great way to get help with open source bugs. Anyway, I've also discovered that Slack and IRC are very different beasts. And IRCCloud account goes a way to helping to get you closer in terms of the history but it's still not the slack experience. Don't get me wrong, I like them both and I far prefer the flexibility and lightness of IRC, but there's no way you're selling that in to a business that needs something that just works. Ironically, Slack is begging to be hacked for industrial espionage so is a pretty dangerous place to have all your business conversations but you know, it's pretty....

lokedhs 9y ago

We also used to use IRC, but then after realising that we wanted some of the features of Slack (a persistent, searchable log of messages for example), so we went and developed such an application that had all the features we needed. It even has some features that Slack still don't have, even though they have hundreds of developers and we were two guys working on the evenings. We also released it fully open source. https://github.com/cicakhq/potato https://github.com/cicakhq/potato

deleted 9y ago
[deleted]