Need to connect a Freenode channel to a room in HipChat? Or want to give customers a simple way to connect to a channel in your Slack team?

Sameroom does that!
Learn more

 Subscribe via RSS

Tag: jabber

Big Company Mergers and Acquisitions: Dealing with Collaboration Systems

By Andrei Soroker

Some of the most common questions we encounter from prospective customers involve mergers and acquisitions: what happens to established non-email collaboration pathways at two companies once they are required to combine?

"Small big" companies—a couple of hundred people on the acquirer side—don't have much of a problem: the acquiree either gets fully absorbed into the internal real-time collaboration system of the acquirer, or a Sameroom-like service is used to establish bridges between the rooms or channels of corresponding departments at both firms.

The reason why "small big" companies don't have much of a problem with this is because they tend to be young enough to have adopted team-centric collaboration tools, like IRC, HipChat, or Campfire at inception (so, they actually have rooms or channels to bridge, and know how to use them), instead of older one-to-one IM services, like AOL, Yahoo, or Microsoft Communicator.

It's the "big big" companies, at least a couple of decades old and with thousands of employees, that tend to run into issues. At such companies, it's common to see heavy reliance on email and phones for nearly all business communication, with "IM" being nothing more than a lightweight interrupt — "hey, you available?", or "what's he talking about" (during a conference call) sort of stuff.

(With plenty of team chat used by small groups in shadow IT mode, but for the purposes of this discussion, we'll pretend that isn't happening.)

At the "big big" companies, equally important to sending these lightweight messages is the concept of presence—color-coded status showing a user as online, away, busy, or offline.

The reason for this is historical: traditional instant messaging and presence systems—IM&P for short—attempt to mimic in software the idea of a factory-type environment where everyone is co-located within the same physical space and one can glance at a chair and see the "presence" status of its occupant.

The presence indicator approach worked reasonably well because when most of these now-"big big" companies hit success and began scaling, they scaled "vertically": to new floors and adjacent buildings, as oppose to "horizontally": across cities and time zones.

Because of this history, when "big big" company IT staff consider the technical aspects of merging two collaboration systems to establish a merger task force involving subgroups from parallel business units at each company, they often envision something like this:


(We didn't connect all the dots, but the idea is that everyone is connected to everyone else individually.)

This is called federation—a way to merge user "rosters" in IM&P systems of two companies.

It's a functionality that exists out-of-the-box in common "big big" company IM&P systems: Cisco Jabber, Skype for Business Server (not Cloud), IBM Sametime, and a few others.

Quite often, federation suffers from an intention-solution conflict: the M&A stakeholders view federation as a way to foster efficient collaboration between related groups at both companies to ease a traditionally-painful and time-consuming integration process, but instead all they get is the old one-to-one instant messaging and presence.

One-to-one communication contradicts the goal of connecting groups not only in the most obvious way—it's one-to-one as oppose to many-to-many—but also by offering diminishing, or even harmful returns in scenarios where openness and transparency of information is pivotal to successful integration of business processes between two companies, each with unique culture, history, and belief system.

Additionally, a traditional federation solution may disappoint because M&A scenarios usually exhibit a dramatic departure from the factory-centric assumption of traditional IM&P: companies tend to be in different geographies and time zones, rendering the concept of "presence" largely irrelevant.

An alternative approach involves another out-of-the-box feature of most IM&P systems: persistent chat rooms.

Persistent chat rooms are available in most "big big" company collaboration systems, like Skype for Business Server (not Cloud) and Cisco Jabber, but are disabled by default in both.

Enabling the feature involves a similar amount of work as enabling federation, but the results—with a little help from Sameroom—would potentially be more aligned with the original requirements:


Setting this up between Cisco Jabber and Skype for Business Server would require using a Sameroom Proxy for each, with the high-level architecture of the integration looking something like this:


The result can be powerful. For example, it becomes trivial to replicate a source code repository event feed in Jabber and Skype for Business. Here is an example of us doing just this, with a Jabber client running on Mac and a Lync/SFB client running on a Windows 8 VM:


The actual data is coming from a Fleep room with GitLab integration enabled:


Anyone with access to one of these rooms can see what's going on.

In this model, users don't see the membership or presence of users in connected rooms—all focus is on content. It's implied that membership will change over time, that occasionally experts may join on a short-term basis, and that third, or even fourth parties—such as agencies or contractors—may be invited to connect rooms from their collaboration environments.

This idea is revolutionary in a way that three-way calling was revolutionary—as in not very, but kind of.

If you're interested in exploring an M&A collaboration environment that uses persistent chat rooms and Sameroom, we can help—reach out to or call us at (415) 483-7743. We can also walk you through enabling persistent chat rooms in your collaboration system.

For information about Sameroom Enterprise, see

For Sameroom Security Overview, see

Announcing Cisco Jabber Integration

img Cisco Jabber is a real-time, XMPP-based communication system deployed on-premise at thousands of enterprises.

Jabber works on a variety of platforms, has named, persistent chatrooms, and direct messaging. It is very much bell and whistle-free when compared to its modern, cloud-based competition. That said, Jabber comes with a unique advantage: it scales across thousands of users, making it a viable option for keeping everyone connected at the largest of companies.

However, teams at large companies often look for those bells and whistles in a chat service. They want integrations, bots, ability to paste code, animated gif support, and excellent mobile apps.

When teams discover more featureful communication solutions, they sign up and begin to re-center their workflows around these new mission control centers. In this way, given enough time, any large company will eventually find itself housing as many cloud team chat instances as it does teams. Such instances get adopted unofficially, with no involvement from systems administrators. Any subscription fees are either expensed or paid out of pocket. (This is called "shadow IT".)

As a result, the landscape of real-time communication tools at large companies ends up extremely fragmented. Jabber continues to be available as the standard IM tool everyone is expected to use, but its adoption tends to plummet. People end up with multiple active IM accounts, so getting a hold of someone turns into an exercise of trying them all. In the end, it's often easier to email.

Our standard solution to the problem of fragmented chat tools (see, for example, Connecting Slack to Skype) doesn't work so well for Jabber, because its runs behind corporate firewalls.

To address this, we built a special Sameroom Proxy Agent that IT can install on-premise. This agent connects to Sameroom, Jabber, and Active Directory. By using this Agent, a company where chat has been fragmented between Jabber and, say, Slack, can help both factions remain connected without having to resort to email.

Installation Instructions

The Sameroom Proxy Agent is available as a Docker image. Before proceeding, you'll need a machine with Docker installed. For Docker installation instructions, see

Once your machine is ready, install the Sameroom proxy agent:

docker run --name sameroom-xmpp -d -p 8080:8080 --restart=always sameroom/sameroom-xmpp-proxy

Once the proxy is running, you can open https://<proxy server IP>:8080 in your browser to see the setup form—you'll have to fill it out.


Note that your Jabber password is never transmitted to the cloud and the proxy never stores it to disk.

Once the setup is complete, you'll be directed to Your Jabber account will be listed on Sameroom Accounts.

At this point, you can add accounts from other services and build Tubes between your on-premise Jabber and cloud systems, like Slack, HipChat, Chatter, or Skype.

Interestingly, you can also use this approach to federate two Jabbers running behind different firewalls.

This is the History of Chat

Click for timeline

When our colleague Mikl Kurkov suggested we make a timeline of chat services and their protocols, we all thought it was a great idea. (Little did we know how many services we’d find!) Today, we’re releasing the timeline, and it’s fucking scary. The number of chat services in the market is staggering.

(If you know someone who's thinking about starting a chat service, have them look over this timeline first—doing so might save him/her some substantial pain.)

Perhaps most interesting is how, for the most part, the current state of things has nothing to do with the infamous chat wars of the ‘90s. These days, everything’s largely peaceful and folks are playing nice. Most groups have their own vision for what features are best—and want to build the best chat service they can. Many start by looking around for a protocol, realize that few support the features they want to offer, and just roll out their own.

These organizations rarely realize the challenges they produce in doing so—and that they’ll lose users, because their service doesn’t speak to other chat providers. They do what they have to—and, in turn, add to the many dozens of protocols that are in no way interoperable. Until, they plug-in Sameroom (the universal translator for chat protocols), and suddenly their little island is connected to all the other chat services, out there.

Click to download the PDF

The source code for the timeline is freely available on GitHub. If you see any inaccuracies or omissions, feel free to file an issue or send a pull request:

The artwork for this project was expertly executed by (Eric Karjaluoto from smashLAB.

Self-Hosted Team Chat Options and Alternatives

by Andrei Soroker and Niral Patel

When you think of team chat, products like Slack, HipChat, Kato, or Skype come to mind. However, these are all cloud services: when you use them, you entrust a key asset of your company—your real-time business communication archive—to a third party.

Both HipChat and Slack had recent security incidents, with Slack’s particularly daunting: their entire user directory was compromised. (Luckily, that news coincided with a $160 million funding round, so nobody noticed.)

Since popular cloud services are expected to be continuously scrutinized by internet outlaws and—eventually—hacked, some IT departments prefer the control that comes with an on-premise option.

This control comes at a cost, however, as there are two significant problems with a self-hosted corporate chat solution.

First, mobile push notifications are very difficult, if not impossible, to set up, meaning all mobile staff (sales, execs, etc) will quietly use another service, such as SMS, AIM, or even Facebook.

Second, company-wide on-premise solutions make it very difficult to configure integrations and chat-driven workflows (chatops) that most modern technical teams consider absolutely essential—such teams are very likely to quietly sign up for a cloud service, only resorting to company-wide chat for cross-team communication.

In this post we’ll take a look at some of the self-hosted solutions available. They range from hobbyist side projects to truly Enterprise—with a capital E.

1. HipChat Server

Atlassian HipChat has been available as a cloud-based professional team chat solution since 2010. In early 2015 HipChat Server was announced, enabling companies to self-host HipChat behind a corporate firewall. Pricing ranges from $10 per year for a team of ten to $72,000 per year for 5000 users.

2. Cisco Jabber

Cisco Jabber started out as Jabber XCP, which was the commercial arm of the open source project (the initial reference implementation of XMPP).

Jabber XCP was acquired by Cisco in 2008 and is available as part of Cisco’s Unified Communications suite of products. Cisco Jabber offers integrations with Microsoft Office applications.

Jabber is sold by resellers, so pricing will vary between installations.

The main issue with Cisco Jabber is that it’s not, strictly speaking, “team chat”, because it lacks open, named, persistent rooms with searchable history. Therefore, a company that deploys Jabber will very likely see groups adopting cloud team chat solutions.

Cisco’s response to this is its own recently-launched cloud team chat solution called Cisco Spark.

3. Self-hosted XMPP Server

A much cheaper alternative to Jabber is a self-hosted XMPP Server.

The best-supported XMPP server is probably MongooseIM, which began life as a fork of ejabberd (the best-known XMPP server) and is supported by Erlang Solutions.

A self-hosted XMPP server will provide a company rudimentary IM, but it is not a replacement for a full-blown team chat solution.

Redundancy, backups, provisions for mobile access and mobile push notifications are the responsibility of the admins running a self-hosted XMPP system.

4. Skype for Business Server (Lync Server)

Over the years, Microsoft has amassed quite a collection of communication services. In addition to Hotmail and Exchange (email), for over 15 years Microsoft ran MSN Messenger, which was used heavily by businesses.

Microsoft became a key early player in cloud-based team chat space with its purchase of Skype in 2011. Skype, in turn, bought GroupMe, which has been known to be used by professional and semi-professional teams for real-time communication.

In addition to this—largely consumer—IM product line, Microsoft has supplied an on-premise real-time communication solution since Exchange 2000, which included Exchange Instant Messenger service. It was replaced in 2003 by Microsoft Office Live Communications Server, which in turn was superseded by Microsoft Lync Server in 2010. The Lync Server comes with a corresponding Lync desktop client.

In 2015, Microsoft announced plans to replace the Lync client with Skype for Business—a hybrid compatible with both the on-premise Lync Server and the cloud Skype network.

Skype for Business will liberate Lync users from having to run two IM programs at the same time (Lync and Skype)—for internal and external communication—but it should not be viewed as a full-fledged alternative to a professional team chat service. IT departments that deploy a company-wide Lync Server should expect to see multiple groups adopting professional team chat services without prior consultation with IT.

Skype for Business / Lync can be purchased through resellers, which means prices will vary.

5. IBM Sametime

IBM Sametime is directly competitive with Microsoft Lync Server and Cisco Jabber. It is an on-premise enterprise communication suite with a wide array of functions, but it is not directly competitive with professional team chat services. Therefore, companies that deploy IBM Sametime should also expect to see groups adopting cloud-based team chat solutions for small team communication.

IBM is likely to announce its own team chat service some time in 2015 or 2016.

6. IRC

“IRC”, in the context of self-hosted group chat systems, refers to collection daemon programs, all claiming compatibility with the IRC protocol. To implement IRC for internal company communication, all you have to do is:

  1. Choose an IRC daemon to deploy. There are many different options.

  2. Designate a machine or VM behind your firewall for the IRC service;

  3. Decide how chat history will be logged and searched by end users. There are multiple options for this, ranging from grepping logs on the IRC host machine to deploying IRC bouncers;

  4. Figure out your mobile strategy: there are IRC mobile clients that will work with publicly-accessible IRC servers, but will not work with a server behind a firewall. VPN is one way of dealing with this issue, but push notifications—if available at all with your IRC setup—will not work without an active VPN connection;

  5. Figure out your backup strategy—if your IRC server experiences a malfunction, you need a way to recover the logs of your company’s business communication;

  6. Figure out your redundancy strategy—if your IRC server experiences a malfunction, the company will lose its key communication channel, which may bring all operations to a standstill. You may want to have a hot-standby server available, with some sort of an automated failover system in place.

7. Let’s Chat

Let’s Chat is an open-source, web-based, XMPP-compatible, self-hosted chat service from Security Compass, released in 2012. There are no mobile apps available and no provision for push notifications.

8. Mattermost

Mattermost is one of the new players in the self-hosted market. It’s an open source team communication solution—interestingly, a spin off from SpinPunch, a video gaming company. The team is already working on an iOS app and has plans for enterprise support.

9. Rocket.Chat

Rocket.Chat is another new face with a unique agenda, providing an open source alternative to both commercial services and IRC. Rocket.Chat has a Slack-inspired webapp, an Electron-based desktop client and, more recently, an iOS app. More importantly, as of August 13, 2015, the project has 2834 stars and 364 clones on GitHub.