14 ms·

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to act

A hundred different chat systems mentioned here. None of them compatible with one another. Well, I guess a couple of them have IRC gateways, but you have to actually set those up. Gee, wouldn't it be nice if you could pick and choose your UI? Pick and choose your "integrations", your "plugins", your client, etc without having to lose your entire userbase, history, contacts? Some sort of open protocol. Urgh, I've been working on this lately and the entire field is depressing. Between one side that doesn't understand the legitimate need for open protocols, and another side that doesn't understand why IRC isn't the end-all-be-all of group chat (and why UX matters), it's just people talking past each other. Every new attempt at making "the slack killer" makes this problem worse, because it comes with its own protocol. Its own users. Etc. PS: If somebody has free time to work on an open source multi-protocol group chat gateway, email me, I have something started.

ex3ndr 11y ago
We are actually trying to make open protocol in https://actor.im https://actor.im with federation with https://matrix.org https://matrix.org. It seems that only Actor and Matrix understand importance of federation.
- scrollaway 11y ago
  Yeah, I heard about it. It looks very promising, good luck.
- lewisl9029 11y ago
  I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy. Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainstream (see email). If any servers are used at all in a privacy-minded app, they need to be zero-knowledge as far as I'm concerned, for actual user data at the very least, if not metadata as well (I realize the latter is an unsolved problem). How does Actor handle user data and message storage?
  - ex3ndr 11y ago
    We have two options - end-to-end (experimental) and only client-to-server encryption. We are looking at ZeroDB to make it end-to-end by default and searchable. We had e2e default encryption but people start to scream after missing their phones and losing all theirs messages :( Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
    - lewisl9029 11y ago
      The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.
  - Arathorn 11y ago
    Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation (http://matrix.org/git/olm http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162 https://matrix.org/jira/browse/SPEC-162. So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should certainly wait for E2E to land).
    - lewisl9029 11y ago
      Glad to see there's been progress on this front! The lack of E2E encryption is literally the last thing holding me back from building apps with Matrix. Can't wait to give it a try! =)
      - zanny 11y ago
        Axolotl has a well defined message structure using established crypto functions. All of them, for example, except Curve25519 are in Crypto++. You can probably fairly easily bake your own, albeit I'd use the olm from Matrix and just make theirs work well first.
  - ar0 11y ago
- dorfsmay 11y ago
  There's been some effort towards integration between SIP and XMPP: https://tools.ietf.org/html/rfc7247 https://tools.ietf.org/html/rfc7247
- e12e 11y ago
  Thank you for mentioning actor - I must have missed it the last time various open (federated) solutions were discussed. It looks like an interesting platform, but I was a bit surprised by what I found at: https://developer.actor.im/docs/encryption https://developer.actor.im/docs/encryption "MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought. But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic). Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption! While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl? In addition, it appears you also use curve25591, possibly an implementation derived from NaCl: https://developer.actor.im/docs/securing-server https://developer.actor.im/docs/securing-server "For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:" So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?
  - ex3ndr 11y ago
    Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform. US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts. For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority. We
    - e12e 11y ago
- chei0aiV 11y ago
  Can you make an open source Telepathy backend so I can use my existing IM client to connect to your network? http://telepathy.freedesktop.org/ http://telepathy.freedesktop.org/
- hobarrera 11y ago
  It's not quite clear how actor.im federates. The "username" is my email, but how does my email map to the server I used to log in? How do other servers know how to reach me?
andrey_utkin 11y ago
> open source multi-protocol group chat gateway What about Spectrum http://spectrum.im/ http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps. What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.
- scrollaway 11y ago
  This is the first time I hear about Spectrum, actually.
- edhelas 11y ago
  XMPP has changed yes. And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP (https://movim.eu/ https://movim.eu/). The main goal of the project is to show that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again. You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e31223abc28b5be3fec5a71bb3 https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)). And Movim is also compatible with Spectrum to offer interconnection with other networks ;)
  - detaro 11y ago
    > And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seems like I'm missing out on good things ;)
    - 11y ago
creshal 11y ago
> Some sort of open protocol. XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…
- Zash 11y ago
  I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?
  - msbarnett 11y ago
    Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.
  - creshal 11y ago
    All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.
    - pyre 11y ago
      What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
      - leonroy 11y ago
        Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.
rekoros 11y ago
Here's a timeline we put together of about 60 incompatible chat services: https://cdn.sameroom.io/chat-timeline.pdf https://cdn.sameroom.io/chat-timeline.pdf Our service Sameroom (https://sameroom.io https://sameroom.io) is a commercial solution to the chat incompatibility disaster, not too different from an AC adapter thingy with a bunch of different plugs, one or two per continent. After implementing the protocols of quite a number of these systems (~20), we're seeing a scary acceleration toward further incompatibility. It's good for our business, but really pretty bad for the world.
- Apocryphon 11y ago
  As it turns out, the tower of Babel is completely self-perpetuating.
- brazeon 11y ago
  Do you plan on open sourcing plugs or any parts of your system?
  - rekoros 11y ago
    You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub. We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(
    - cyphar 11y ago
      Right, but surely if you're selling it that's much more incentive for a cease and a desist (regardless of whether it is free software).
      - rekoros 11y ago
        Actually I don't think so. The main thing the owners of big networks are afraid of is spam. We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.
dandelany 11y ago
You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially displayed element. The only thing it may not handle well is file uploads... but even then, I seem to recall IRC having built-in support for sending files?
- strong_code 11y ago
  It has DCC protocol built in, but it isn't nearly as robust as most would like for it to be.
- maaku 11y ago
  These services are really replacements for IRC bouncers, which are not as well standardized (but should be).
- scrollaway 11y ago
  > is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them. Look into ircv3 (http://ircv3.net/ http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.
  - haroldp 11y ago
    I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things? If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?
    - scrollaway 11y ago
bazingatossr77 11y ago
IRC Cloud is based on IRC: https://www.irccloud.com/ https://www.irccloud.com/
amelius 11y ago
> A hundred different chat systems mentioned here. None of them compatible with one another. Obligatory xkcd reference: ... ok, never mind, you probably all know which one I mean.
fiatjaf 11y ago
It's easier to write your own protocol, that's the reason. Laziness.
- pekk 11y ago
  Have you implemented the IRC protocol? It's horrible.
- zanny 11y ago
  I wrote a Matrix client library in Qt about three weeks ago, and it was really braindead simple. JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.
david_ar 11y ago
Note that rocket chat can federate [1] over matrix [2], and I believe mattermost can as well. [1] https://matrix.org/docs/projects/as/rocket-chat-federation.html https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org https://matrix.org
thescriptkiddie 11y ago
> Some sort of open protocol. https://en.wikipedia.org/wiki/Internet_Relay_Chat https://en.wikipedia.org/wiki/Internet_Relay_Chat https://en.wikipedia.org/wiki/XMPP https://en.wikipedia.org/wiki/XMPP https://en.wikipedia.org/wiki/Session_Initiation_Protocol https://en.wikipedia.org/wiki/Session_Initiation_Protocol
- viraptor 11y ago
  SIP is not am IM protocol. There's one crammed on top of it https://en.wikipedia.org/wiki/SIMPLE_%28instant_messaging_protocol%29 https://en.wikipedia.org/wiki/SIMPLE_%28instant_messaging_pr... but SIP is just a framing for it.
coroutines 11y ago
As someone somewhat related to an IRC project, it's frustrating talking to people who love Slack because most of what they want is something that would be supported in an IRC client - not the IRC protocol. Semi-related: IRCv3 is an advance in the right direction, but I wish they would make huge breaking changes now - instead of introducing new standards to manage a migration to "later IRC". Two things I want to see are IRC encoded as JSON, and TLS-only servers in the standard as a requirement. They added message tags which I think just makes IRC ridiculous to parse - if the objective is to extend IRC and add ancillary data to the message they should just use JSON already. I think it's a bad move to allow some intermittent migration path if we all know the end-game is IRC encoded as JSON. It'd be dirt-simple to autodetect if you're receiving JSON or traditional IRC, too. You don't need a CAP exchange to tell you "oh look, it's gonna be fucking json, m8". An example a feature IRC would need to change for is the ability to edit messages. Slack lets you go back and correct already-submitted messages. You don't have this ability in IRC - and there are ethical reasons to not support it. Personally I'd be in favor of IRC having a command for editing messages, and then clients keeping the entire history of edited messages - so you can always see the original. It's not like the server can take that data back - it's jsut assumed clients would show only the latest, revised version of a message. I could also see having the IRC server support a virtual DCC user to upload files to - so then you could emulate file attachments like you have on Slack. This is something that can be abused though - file uploads are a security and DoS concern. Slack can support certain things because the infrastructure is paid for - with IRC networks it's largely a "free" operation. In the past I've made a "Hookbot" that triggers and POSTs to outside services just like Slack. On some IRC networks there are network-vetted bots you can request in your channel to configure and make use of. You can largely support everything Slack does in existing IRC, we just needs standards to add some coherency and expectations for developers/users. UX does matter, I completely agree with you - IRC needs to change minimally to support those Slack-like features, though. Clients need to change. Most of the draw of Slack is embedding linked items in the chat for convenient viewing. Even icky Mibbit does that :p
bphogan 11y ago
Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything. If I had the resources and the money, I'd focus on a good modern IRC client and server. Am I wrong?
- foolfoolz 11y ago
  i think the #1 value add from slack/hipchat is that it's hosted for you. we spend thousands of man-hours each month and year keeping our servers up. uptime is hard. chat is not hard. historical chat is not hard. when chat is down, your business is at risk. there's other services at my company we pay for that aren't very complicated - we just don't want to host it. paying $5/user/mo for chat that is always up is easier than keeping it up yourself. your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
  - bphogan 11y ago
    Makes sense. Although I take issue with "when chat is down your business is at risk." Pick up a phone. Use Skype. Send email. Business was done for thousands of years before chat apps. :D
    - thenomad 11y ago
      That works less well if, for some reason, your business is significantly built around chat (Live Chat for sales, for example). It's perfectly possible to pivot your sales funnel, but it's not something you can do in two hours whilst the chat server's down.
      - 11y ago
Negative1 11y ago
re: Open Protocol, isn't XMPP a viable open source standard?
nso95 11y ago
Make a good irc client
chei0aiV 11y ago
I think Telepathy was ahead of its time. Shame it didn't get much adoption outside of Nokia and is now on life-support: http://telepathy.freedesktop.org/ http://telepathy.freedesktop.org/
- goffi 11y ago
  You may want to check http://salut-a-toi.org/ http://salut-a-toi.org/ then (I'm working on it), we have a similar architecture and it's a very active project, XMPP only though.
conanbatt 11y ago
If you opened your chat, you would be losing the capacity to own the people in your chat and thus never get fidelization (or monetization). Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.
- scrollaway 11y ago
  Imagine that. All the money TBL could have made had he kept the web closed.
qznc 11y ago
I might be alone here, but I don't see the problem. I also do not believe that federation or interop would be a good feature for group chats. You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label. And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard. What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions. (disclaimer: I slightly exaggerated to play devil's advocate)
- slang800 11y ago
  "One user sends an image and the other cannot display it" deals with features between two clients... I fail to see how this would be a more general issue with allowing different UIs. Especially since most chat clients do support the same features. That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist. And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.

ex3ndr 11y ago

We are actually trying to make open protocol in https://actor.im https://actor.im with federation with https://matrix.org https://matrix.org. It seems that only Actor and Matrix understand importance of federation.

scrollaway 11y ago
Yeah, I heard about it. It looks very promising, good luck.
lewisl9029 11y ago
I haven't looked into actor much yet, but the last time I looked at Matrix, my main concern was how much implicit trust users needed to place in homeserver providers (messages and user profiles are stored in plaintext). Unless this has changed, I don't find it viable for any app that values user privacy. Even federated networks eventually gravitate towards a large degree of centralization once the tech becomes mainstream (see email). If any servers are used at all in a privacy-minded app, they need to be zero-knowledge as far as I'm concerned, for actual user data at the very least, if not metadata as well (I realize the latter is an unsolved problem). How does Actor handle user data and message storage?
- ex3ndr 11y ago
  We have two options - end-to-end (experimental) and only client-to-server encryption. We are looking at ZeroDB to make it end-to-end by default and searchable. We had e2e default encryption but people start to scream after missing their phones and losing all theirs messages :( Also we had Tor-enabled client, but Tor is not suitable for mobile apps.
  - lewisl9029 11y ago
    The possible integration with ZeroDB definitely sounds interesting! Really hoping that works out for you guys.
- Arathorn 11y ago
  Matrix signs all of its messages to avoid homeserver providers tampering with message history. Actual encryption however requires E2E encryption, which is in the wings via our "Olm" Axolotl implementation (http://matrix.org/git/olm http://matrix.org/git/olm). Progress can be tracked at https://matrix.org/jira/browse/SPEC-162 https://matrix.org/jira/browse/SPEC-162. So I don't think you should reject Matrix on trust issues quite yet (although if you're really worried you should certainly wait for E2E to land).
  - lewisl9029 11y ago
    Glad to see there's been progress on this front! The lack of E2E encryption is literally the last thing holding me back from building apps with Matrix. Can't wait to give it a try! =)
    - zanny 11y ago
      Axolotl has a well defined message structure using established crypto functions. All of them, for example, except Curve25519 are in Crypto++. You can probably fairly easily bake your own, albeit I'd use the olm from Matrix and just make theirs work well first.
- ar0 11y ago
dorfsmay 11y ago
There's been some effort towards integration between SIP and XMPP: https://tools.ietf.org/html/rfc7247 https://tools.ietf.org/html/rfc7247
e12e 11y ago
Thank you for mentioning actor - I must have missed it the last time various open (federated) solutions were discussed. It looks like an interesting platform, but I was a bit surprised by what I found at: https://developer.actor.im/docs/encryption https://developer.actor.im/docs/encryption "MTProto v2 Rev3 enables encryption support to replace or enchanse TLS one." So far so good - here's someone that's built on top of NaCl and built a legacy-free encryption system on top of well tested, known primitives, I thought. But: "Actor encrypts message with US encryption and then again encrypt with Russian encryption that in result guarantee absolute encryption streight" (sic). Uh. This sounds like applying a "political" reasoning to layering security: AES might be backdoored by NSA, GOST(?) might be backdoored by the FSB -- but using both, only double-agents will be able to foil our encryption! While the truth is probably that you're know vulnerable to buffer overflows or other more mundane software errors in the now double-sized encryption code -- and get none of the (potential) benefits of a clean, modern architecture on top of just NaCl? In addition, it appears you also use curve25591, possibly an implementation derived from NaCl: https://developer.actor.im/docs/securing-server https://developer.actor.im/docs/securing-server "For secure communications Actor Server have to be configured with Curve25519 keys. To generate them, use actor-cli util:" So that's three codebases worth of bugs, rather than one. Any plan to simplify this part?
- ex3ndr 11y ago
  Our encryption is based on Java and everywhere we check buffer overflows and possible timing-attacks. Hopefully we use AES and SHA256 that is easy to validate. Also Instead of using N code bases (one for each platform) we reduce it's amount by conversing sources from java to other languages for every platform. US-based encryption is taken directly from BouncyCastle, time-proven library for Java. Russian implementation can contain bugs, yes, but i can guarantee that there are no timing or overflow attacks possible. Even when we will have broken russian layer, us layer will be safe. Also we are on the way to make everything verified by 3rd parties and seal cryptography parts. For key exchange we use curve25519. Implementation is taken directly from Signal and this app is trusted by majority. We
  - e12e 11y ago
chei0aiV 11y ago
Can you make an open source Telepathy backend so I can use my existing IM client to connect to your network? http://telepathy.freedesktop.org/ http://telepathy.freedesktop.org/
hobarrera 11y ago
It's not quite clear how actor.im federates. The "username" is my email, but how does my email map to the server I used to log in? How do other servers know how to reach me?

andrey_utkin 11y ago

> open source multi-protocol group chat gateway What about Spectrum http://spectrum.im/ http://spectrum.im/ ? I am successfully using Spectrum as gateway to Skype (except groupchats ATM, some bugfixing pending) and IRC from my XMPP client apps. What about XMPP in the whole? It looked depressing few years ago, but times have changed, I can help you to catch up with nice novelties.

scrollaway 11y ago
This is the first time I hear about Spectrum, actually.
edhelas 11y ago
XMPP has changed yes. And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). I'm personally working on Movim, a nice-looking "Social-IM" client fully based on XMPP (https://movim.eu/ https://movim.eu/). The main goal of the project is to show that we have now all the tools to build a decentralized, standard and universal IM (and also social !) network without reinventing the wheel again and again. You can have a look at our latest release-note as well https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e31223abc28b5be3fec5a71bb3 https://pod.movim.eu/?node/pubsub.movim.eu/Movim/f5f883e3122... (this blog post has been published/edited using Movim and XMPP ;)). And Movim is also compatible with Spectrum to offer interconnection with other networks ;)
- detaro 11y ago
  > And we now have some nice clients that are compatible together and stable servers with a bunch of nice features (multi-devices sync, history management, ACK, rich messages, messages edition, encryption, battery management, push notifications…). Can you recommend a few? I haven't looked into XMPP in detail for a while, because the clients I've been using are "good enough and I didn't bother with mobile), but it seems like I'm missing out on good things ;)
  - 11y ago

creshal 11y ago

> Some sort of open protocol. XMPP seems to be rather dead, for various reasons, and no real contender for a replacement has sprung up. I guess there always is, and always will be IRC…

Zash 11y ago
I use XMPP every day. All my friends are on XMPP. What makes you think XMPP is dead? What are "various reasons"?
- msbarnett 11y ago
  Google's abandonment of it was a big, big blow. 90% of my contacts are no longer available via XMPP.
- creshal 11y ago
  All the servers available for it suck. All the clients available for it suck. I know, I'm using it daily too, but I don't see it gaining more traction that it already has ever again.
  - pyre 11y ago
    What sucks about (e.g.) Adium? I haven't had any major issues with it other than the fact that it doesn't seem to be too actively updated. My biggest complaint is lack of protocol support for other things (e.g. GTalk vs. Hangouts), but that's on libpurple, and the lack of open protocols by the providers.
    - leonroy 11y ago
      Developer interest is on the wane in pretty much every XMPP project out there. That's the main issue. XMPP is very much alive in large businesses, especially for system to system interop, but as far as client to server goes I don't see a compelling XMPP client - where's voice, video, chat archiving for example? Compare any XMPP client to Skype for instance and they're not even remotely close.

rekoros 11y ago

Here's a timeline we put together of about 60 incompatible chat services: https://cdn.sameroom.io/chat-timeline.pdf https://cdn.sameroom.io/chat-timeline.pdf Our service Sameroom (https://sameroom.io https://sameroom.io) is a commercial solution to the chat incompatibility disaster, not too different from an AC adapter thingy with a bunch of different plugs, one or two per continent. After implementing the protocols of quite a number of these systems (~20), we're seeing a scary acceleration toward further incompatibility. It's good for our business, but really pretty bad for the world.

Apocryphon 11y ago
As it turns out, the tower of Babel is completely self-perpetuating.
brazeon 11y ago
Do you plan on open sourcing plugs or any parts of your system?
- rekoros 11y ago
  You can see what happens to OS projects that work with WhatsApp, Skype, and some of the other heavily guarded walled gardens -- cease & desist orders, carried out by GitHub. We have absolutely no interest in joining that list, which unfortunately means the answer - for the time being - is no :(
  - cyphar 11y ago
    Right, but surely if you're selling it that's much more incentive for a cease and a desist (regardless of whether it is free software).
    - rekoros 11y ago
      Actually I don't think so. The main thing the owners of big networks are afraid of is spam. We provide a ridiculously expensive way to connect, say, Slack to Skype, which is ==great for Skype==, from almost every possible angle. It means Skype users can stay on Skype instead of switching to someone else's Slack team.

dandelany 11y ago

You're certainly right that the UX of most IRC clients is seriously lacking compared to eg. Slack. But one thing I've always wondered - is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps? There's no reason why the protocol itself has to handle UX features like emoji/embedding/etc. - just send a text token over the wire and have the client interpret it as a specially displayed element. The only thing it may not handle well is file uploads... but even then, I seem to recall IRC having built-in support for sending files?

strong_code 11y ago
It has DCC protocol built in, but it isn't nearly as robust as most would like for it to be.
maaku 11y ago
These services are really replacements for IRC bouncers, which are not as well standardized (but should be).
scrollaway 11y ago
> is there any reason that IRC couldn't be used as the underlying protocol for these Slack-esque apps The IRC protocol is old. It predates HTTP. Some things are possible in theory, but pointless if no client supports them. Look into ircv3 (http://ircv3.net/ http://ircv3.net/), they're writing new specs for the IRC protocol to build exactly what you're talking about. It's very promising, although IMHO too little, too late - Matrix looks like it's going to take the crown eventually.
- haroldp 11y ago
  I'm sure that I'm over simplifying, but can't you just put tokens or markdown right in the chat for those sort of things? If you have an old, flat IRC client, it's ugly but you can figure it out. If you have a supported client you get a nice UI?
  - scrollaway 11y ago

bazingatossr77 11y ago

IRC Cloud is based on IRC: https://www.irccloud.com/ https://www.irccloud.com/

amelius 11y ago

> A hundred different chat systems mentioned here. None of them compatible with one another. Obligatory xkcd reference: ... ok, never mind, you probably all know which one I mean.

fiatjaf 11y ago

It's easier to write your own protocol, that's the reason. Laziness.

pekk 11y ago
Have you implemented the IRC protocol? It's horrible.
zanny 11y ago
I wrote a Matrix client library in Qt about three weeks ago, and it was really braindead simple. JSON in, JSON out. HTTP codes tell you what response you got. TLS on an https connection for secure communications. WebRTC for voice calls, and you just query the API for the signaling server to use.

david_ar 11y ago

Note that rocket chat can federate [1] over matrix [2], and I believe mattermost can as well. [1] https://matrix.org/docs/projects/as/rocket-chat-federation.html https://matrix.org/docs/projects/as/rocket-chat-federation.h... [2] https://matrix.org https://matrix.org

thescriptkiddie 11y ago

> Some sort of open protocol. https://en.wikipedia.org/wiki/Internet_Relay_Chat https://en.wikipedia.org/wiki/Internet_Relay_Chat https://en.wikipedia.org/wiki/XMPP https://en.wikipedia.org/wiki/XMPP https://en.wikipedia.org/wiki/Session_Initiation_Protocol https://en.wikipedia.org/wiki/Session_Initiation_Protocol

viraptor 11y ago
SIP is not am IM protocol. There's one crammed on top of it https://en.wikipedia.org/wiki/SIMPLE_%28instant_messaging_protocol%29 https://en.wikipedia.org/wiki/SIMPLE_%28instant_messaging_pr... but SIP is just a framing for it.

coroutines 11y ago

As someone somewhat related to an IRC project, it's frustrating talking to people who love Slack because most of what they want is something that would be supported in an IRC client - not the IRC protocol. Semi-related: IRCv3 is an advance in the right direction, but I wish they would make huge breaking changes now - instead of introducing new standards to manage a migration to "later IRC". Two things I want to see are IRC encoded as JSON, and TLS-only servers in the standard as a requirement. They added message tags which I think just makes IRC ridiculous to parse - if the objective is to extend IRC and add ancillary data to the message they should just use JSON already. I think it's a bad move to allow some intermittent migration path if we all know the end-game is IRC encoded as JSON. It'd be dirt-simple to autodetect if you're receiving JSON or traditional IRC, too. You don't need a CAP exchange to tell you "oh look, it's gonna be fucking json, m8". An example a feature IRC would need to change for is the ability to edit messages. Slack lets you go back and correct already-submitted messages. You don't have this ability in IRC - and there are ethical reasons to not support it. Personally I'd be in favor of IRC having a command for editing messages, and then clients keeping the entire history of edited messages - so you can always see the original. It's not like the server can take that data back - it's jsut assumed clients would show only the latest, revised version of a message. I could also see having the IRC server support a virtual DCC user to upload files to - so then you could emulate file attachments like you have on Slack. This is something that can be abused though - file uploads are a security and DoS concern. Slack can support certain things because the infrastructure is paid for - with IRC networks it's largely a "free" operation. In the past I've made a "Hookbot" that triggers and POSTs to outside services just like Slack. On some IRC networks there are network-vetted bots you can request in your channel to configure and make use of. You can largely support everything Slack does in existing IRC, we just needs standards to add some coherency and expectations for developers/users. UX does matter, I completely agree with you - IRC needs to change minimally to support those Slack-like features, though. Clients need to change. Most of the draw of Slack is embedding linked items in the chat for convenient viewing. Even icky Mibbit does that :p

bphogan 11y ago

Edit: looks like someone asked a similar question below. I'm curious though. What is it about IRC that makes it not a good choice? It seems to me that the biggest issue non-nerds care about is the user experience. And I feel that if people wanted to, that could be fixed. And if we really wanted to, we could extend IRC to do what we want and deal with its shortcomings. I use a nice web gateway (kiwi) on top of an IRC channel for my student office hours and it's easy. They just supply a username and log in. No software to install, the UI looks nice, and students don't have to sign up for anything. If I had the resources and the money, I'd focus on a good modern IRC client and server. Am I wrong?

foolfoolz 11y ago
i think the #1 value add from slack/hipchat is that it's hosted for you. we spend thousands of man-hours each month and year keeping our servers up. uptime is hard. chat is not hard. historical chat is not hard. when chat is down, your business is at risk. there's other services at my company we pay for that aren't very complicated - we just don't want to host it. paying $5/user/mo for chat that is always up is easier than keeping it up yourself. your use case is very different, and i wouldn't expect any pay-for-chat service to make any sense for it
- bphogan 11y ago
  Makes sense. Although I take issue with "when chat is down your business is at risk." Pick up a phone. Use Skype. Send email. Business was done for thousands of years before chat apps. :D
  - thenomad 11y ago
    That works less well if, for some reason, your business is significantly built around chat (Live Chat for sales, for example). It's perfectly possible to pivot your sales funnel, but it's not something you can do in two hours whilst the chat server's down.
    - 11y ago

Negative1 11y ago

re: Open Protocol, isn't XMPP a viable open source standard?

nso95 11y ago

Make a good irc client

chei0aiV 11y ago

I think Telepathy was ahead of its time. Shame it didn't get much adoption outside of Nokia and is now on life-support: http://telepathy.freedesktop.org/ http://telepathy.freedesktop.org/

goffi 11y ago
You may want to check http://salut-a-toi.org/ http://salut-a-toi.org/ then (I'm working on it), we have a similar architecture and it's a very active project, XMPP only though.

conanbatt 11y ago

If you opened your chat, you would be losing the capacity to own the people in your chat and thus never get fidelization (or monetization). Think of a bar that lets you bring drinks from other bars. It doesnt have good prospects.

scrollaway 11y ago
Imagine that. All the money TBL could have made had he kept the web closed.

qznc 11y ago

I might be alone here, but I don't see the problem. I also do not believe that federation or interop would be a good feature for group chats. You want to pick and choose your UI? That is an anti-feature. One user sends an image and the other cannot display it because he uses a terminal client. One user sends an emoji, another client only displays a box, because he has no glyph in his font. This is already a problem with XMPP. It has lots of nice features, but each requires server and client to support it. There is no "Full XMPP" label. And since you prominently talk about the protocol: XMPP probably has all the features one needs. Why hasn't it won yet? Because the complexity of all server-client combinations makes a good user experience too hard. What is the problem with using different clients/networks for different groups? Why do you want to mix work and private groups into the same app? What does matter (especially for web apps) is a unified authentication scheme (Mozilla Persona would be my favorite), so I can quickly switch between them and do not need lots of accounts. Thus: Federated accounts, but diverse chat solutions. (disclaimer: I slightly exaggerated to play devil's advocate)

slang800 11y ago
"One user sends an image and the other cannot display it" deals with features between two clients... I fail to see how this would be a more general issue with allowing different UIs. Especially since most chat clients do support the same features. That argument is like saying we should only have one HTML browser because text-based browsers like w3m could exist. And "one user sends an emoji, another client only displays a box, because he has no glyph in his font" is an issue between different operating systems. Even in a non-federated system like Slack I used to get emojis from people using iOS8 that don't display properly.