Indeed. There are lots of apps that cover parts of its functionality, but not all. We keep trying to introduce new alternatives at work, but to date nothing has passed the test.
Calls, group calls, chat, group chat, video, screenshare. For one communications client those are the boxes it needs to tick. Any suggestions?
Tox does all of that. XMPP does all of that. WebRTC does all of that. There are tons of shitty proprietary clones of Skype that also do all of that, too. There are plenty of options, people just don't use them because all their friends are on Skype.
Tox is getting there, but it doesn't appear to support asynchronous messaging that syncs later when some of the people in a chat are offline. If that's wrong let me know.
>XMPP does all of that.
That's like saying "TCP does all that". Would you like to name programs that support the full list?
>WebRTC does all of that.
As far as I can tell WebRTC has nothing to do with chat.
Asynchronous messaging depends on a server to hold your messages for delivery when you go offline. That implies some company being behind the service to host that server, along with centralization and the ability of deanonymization. I'm sure there are clients that do support it, but I wouldn't want to use it. Proper Tox style would probably be to host your own bouncer server, like IRC, for that use.
I don't actually use XMPP, but a quick Google gives a list that do. https://en.wikipedia.org/wiki/Comparison_of_instant_messagin... for example. Would you be upset if I said "IRC does that" if you asked for messaging? Why aren't you upset that I pointed at Tox, which is also a protocol with separate implementations? Your point about TCP, while meant to be a critism, is actually spot on: It is a protocol. Anyone can implement it and talk to all other XMPP (or Tox!) clients, unlike Skype which is completely proprietary and closed ecosystem.
Pointing at only one client shows favoritism and is disingenuous, since you could point out "<x> doesn't implement <y>!" when another client does, while if it's supported in the protocol it CAN be support by any of the clients.
You're actually right about the WebRTC point: it inherently doesn't support text, it's for p2p signaling. Most implementations do have a textbox for communication, however, and have the same benefit as Tox or XMPP: It's a protocol. Just because one site doesn't do it, doesn't mean any other site can't and inter-op with all other providers.
>Asynchronous messaging depends on a server to hold your messages for delivery when you go offline.
You can get 90% of the benefit by having other clients in the chat act as relays for that chat. No centralization required. You'd only need a bouncer for specific situations, like mobile<->mobile chat with all desktop clients shut off.
>Would you be upset if I said "IRC does that" if you asked for messaging?
If I asked for just messaging, I would accept "IRC". But if I ask for video chat, and a tiny fraction of IRC clients did video chat, I would not accept "IRC" as an answer. If you want to name a protocol, the implementations need to have widespread support for the entire list of features. Theoretical support is not good enough. I agree that universal support is unnecessary, but widespread support is a must.
It looks like "XMPP+Jingle" is a pretty good answer, but I'd have to look into it more.
I don't actually have any idea about how group chats are implemented in Tox, but I don't see why you can't send messages to the people in the group to redistribute when people get back. It sounds like it might have history consistency issues, but maybe they already do that.
I assumed you were talking about one-on-one message relaying, which is probably what most people would care about. That can't really be solved, since one of the goals of Tox is also to prevent 3rd parties from being able to tell who you are talking to. Can't do that if you have to broadcast to users "send this message to <x> when they get back"...
From what I could see group chats don't have it yet. And note that I said multiple clients, not multiple users. If you or your chat partner have their desktop turned on it should be able to take messages and forward them to your cell phone.
No suggestions, but I think those features scream "Slack" in my opinion. It would make a lot of sense to have those features in a service that is the center of communication for many teams anyway.
I've been using Slack (https://slack.com/) for a while too... it does everything useful, and everything it doesn't do natively, there's an integration for. You can do:
- Private chat with one or more parties
- Open Group chat via channels (both private and public channels)
- Voice/Video via numerous integrations including Bluejeans, Appear.in, Skype, Hangouts, you name it.
- ChatOps via services like IFTT & Zapier or even your own custom bridge into your network.
- Get notifications right in Slack from your source control, build servers, JIRA, Confluence and any number of other services via webhook integrations.
- A billion other wicked cool integrations (https://slack.com/apps) that allow you to do just about anything, including the eternally useless, often inappropriate and highly amusing Giphy.
- It's free(ish)... the featureset is restricted on the free account, but it has enough to be useful to small startups even of adhoc members. For teams there is a small per user/per month charge which unlocks a wealth of enterprise ready features.
- It's searchable
Highly recommended and well worth a look for small and large teams alike.
Calls, group calls, chat, group chat, video, screenshare. For one communications client those are the boxes it needs to tick. Any suggestions?