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

Andrei Soroker

37 posts

Slack Shared Channels vs Sameroom Tubes

By Andrei Soroker

Yesterday, Slack introduced Shared Channels — essentially, a native equivalent to Slack-to-Slack Sameroom Tubes.

We first heard about Shared Channels a while back — a quick search yields a TechCrunch article from March 2016, but I seem to recall even earlier rumors.

The anticipation of the Shared Channels feature helped all of us at Sameroom avoid focusing on the Slack-to-Slack use case too seriously, since it was just a matter of time before our version became démodé.

Or, so we thought!

After attending a detailed demo at the Frontiers conference yesterday and learning a bit more about the feature, I have reasons to believe capitulation is premature.

The Demo

At the demo area, there were three large tables with two beautiful iMacs on each. When I walked up to one of the tables and requested to see Shared Channels, the host explained that each station represents a separate company — Marketing Consultants, Engineering Consultants, and the mothership firm itself (his table) — and proposed that we send a message to the Marketing company.

He joined one of the shared channels in the mothership firm's Slack team and posted a message.

My eyes automatically wandered to the second iMac on our table, but it was asleep.

"So, did it work?" I asked.

"Yeah, let's go find the other team, I'm actually not sure which table it's at," said the host.

There was some crowding at the other tables, so we had to wait in line.

Twice, since the Marketing table ended up being the second one.

When we found the other team, and the correct Shared Channel within it, I had my confirmation: it worked!

The host then posted a response.

When we walked back to the original station to make sure the response got across, we had to wait for a small group of conference goers to free up the iMac.


To botch a demo of one of the most revolutionary Slack features ever launched this badly suggests that the company has not necessarily internalized the potential behind the concept, which may spell friction in marketing, support, and further development. Further observations, listed below, seem to contribute to this suspicion.

Paid Teams Only

Shared Channels are only available to paid teams (once the feature leaves Beta and enters GA, that is). Sameroom, on the other hand, can be easily used to create Tubes — our version of Shared Channels — between free Slack teams. (This does not mean an entirely free lunch, unfortunately, since Sameroom is not free.)

And now, it's time for a minor confession: I've known about Slack since February 2013 and I have never been a member of a paid Slack team. I'm not your usual Slack user, obviously, but the number of folks who rely on the product almost as much as they rely on oxygen and have absolutely no intention of ever paying for Slack is truly, obscenely, staggering.

This is why Slack began tightening the screws by hiding actual features — not just access to history or method of authentication — behind a paywall.

While I fully understand the rationale, I believe hiding real features from free users is a strategic mistake, since Slack's primary challenge, as it stands, isn't necessarily to make money, but to transform workplace communication from phone calls, emails, and faxes to the bliss of ever-searchable, always-available, omni-modal, self-categorizing organizational memory.

And so, I'm experiencing a bit of a déjà vu.

The first amazing, transformational feature Slack tucked away was User Groups. This is one of the main reasons why, in the humble opinion of this industry observer, the feature remains essentially unused, since most teams that upgrade from the free tier are likely to be very mature, with all the integrations and workflows long established.

Another likely reason for User Groups to have seen underwhelming adoption is the requirement that admins be intimately involved with their management.

Speaking of admins, for Shared Channels, it's...

Admins Only, on Both Ends

It's understandable to only allow Slack administrators the ability to initiate and accept Shared Channels — anything else can be viewed as a security risk.

When we pitch Sameroom to CIOs, they often ask about the option to clamp down on their users' ability to share internal chatrooms and channels with the outside world. Our response is always the same: let them do it, but make sure that a) you know about them doing it by subscribing to the Sameroom Security Log and b) tell your users that you know they're doing it.

In our experience, the overwhelming majority of cross-organizational Sameroom connections are initiated and accepted by non-admins.

To draw an extreme analogy, asking an admin to configure a Shared Channel is akin to asking an admin to send a group email that includes recipients from a different domain — and to get an admin from that other domain to accept it.

It's very likely, that with a feature like Shared Channels, erring on the side of minimizing a perceived security risk will drive a major wedge into usability.

Now, about domains: just imagine if you could only send a group email to members of only one other company? Ouch! And yet...

Only One Other Company Can Share Your Channel

It's true! You can only share a Slack channel with at most one other company.

If you need to get your Marketing Firm and your Design Shop in the same space, you have to use Sameroom, email, or Skype.

While this is a major limitation, the overwhelming majority of users will find it acceptable for the time being. In our experience, most complex Sameroom topologies involve a public IRC or Gitter channel, where, say, multiple companies want to keep track of #python on Freenode from their Slack, HipChat, or Google Hangouts.

It goes without saying, but...

Shared Slack Channels are for Slack Users Only

Fate has it so that, in 2017, Slack is only going to share its channels with Slack.

Interoperability is dead and gets deader with each new arrival into the team messaging camp (we're expecting Atlassian's HipChat replacement, Stride, and Google's Hangouts Chat to diversify the pool of available protocols further, later this year).

As dreadful as it is, this escalating impasse has created an interesting niche for us at Sameroom, where we will continue to quietly translate and forward messages and files between teams, no matter where their work happens.

Announcing Rocket.Chat Integration

By Andrei Soroker

I just opened my conversation with Gabriel Engel, the founder of Rocket.Chat, and scrolled to its very beginning in August 2015:


We had a great exchange, but didn't get very far in terms of agreeing to work together. The conversation happened shortly after Rocket.Chat launched and Gabriel was still in the planning stages of his world domination strategy.

Over the next eighteen months, Rocket.Chat became quite popular and found a commercial niche among organizations looking for self-hosted, open-source, custom (or white-labelled) real-time collaboration solutions. And, as it eventually happens to all chat systems that experience success, interoperability—or lack thereof—came up.

I don't know the exact reason why Gabriel reached out to us with a request for integration, but he was serious: it was needed "asap" and we had the full attention of Bradley Hilton, a staff Rocket.Chat developer.

Bradley set us up with a staging environment running the latest build, we stood up a sameroom between Google Hangouts and Fleep for seamless, safe, and compliant cross-team communication, and, after just a few weeks of Bradley tweaking the Rocket.Chat protocol, the integration went live.

Today, we're happy to announce the integration of Rocket.Chat with, which enables Rocket.Chat users to connect rooms and DMs from their home Rocket.Chat host with about two dozen other chat services, including Slack, Skype, HipChat, Google Hangouts, Mattermost, and Fleep.

For a list of all possible integration, visit

If you have any questions or need help with the integration, ping us on Twitter or send an email to

Startup Death Zone

By Peter Hizalev

The metaphor of climbing a mountain is often used to describe the struggle of building a business. I want to take this metaphor a bit further. In high altitude mountaineering, there is a concept called the Death Zone. As climbers move up a mountain, they eventually reach an altitude where there is so little oxygen, any unplanned stay will result in disaster—thus the Death Zone. This altitude is not an absolute number: it may depend on the distance from the nearest camp, the amount of climbing infrastructure installed along the way, and so on. The key is to carefully plan the entry and exit from the Death Zone, and to focus on minimizing the time spent there. To do this right, it takes a lot of preparation and much practice below the Death Zone.

Let’s see how this translates to building a business. In the early days, a business relies on a handful of founders and key employees. Their main focus is to find a repeatable and scalable business model, often called the "product-market fit". This tight group is motivated by owning a big share of a yet-to-be-valuable company as well as by having fun in a highly transparent and informal environment. If things go well, the group may eventually agree that a product-market fit is found. What's interesting is that while there might be a good amount of evidence to support this, a major leap of faith is still required to prove that it works "in the wild", as an actual business. And to prove this, the company needs to grow. Enter the Startup Death Zone.

The company increases headcount to achieve scale, to get to the fundamental proof of having a working product-market fit. New employees are different from that initial “special ops” team in that they are less excited about high-stakes games, an informal organizational structure, and unpredictable working hours. These new employees join a company that has graduated from the proverbial garage and is about to become a real business. They are motivated by good salaries and stock options, but, most importantly, they are motivated by having the feeling of riding a rocket ship.

And therein lies the grave danger of the Startup Death Zone. The only way for a company to survive is to grow quickly while in the Startup Death Zone. The only way for a mountaineer to survive is to move quickly and purposefully while in the Death Zone. A seemingly minor slowdown in company growth may trigger a disastrous cycle, when even a little bit of doubt among employees sets off a real slowdown, causing more doubt. A minor mistake of a mountaineer exposes her to the increased possibility of another minor mistake, and when minor mistakes compound, things can quickly spiral out of control and lead to tragedy. Overnight, an awesome startup can turn into a toxic wasteland. And, in a matter of minutes, a seemingly well-run expedition can turn into a struggle for survival.

A successful company comes out of the Death Zone when scale has been proven—it continues to operate as a well-oiled money-making machine independently, or joins forces with another company. A successful expedition comes out of the Death Zone when the mountain has been submitted and the most dangerous part of the descent is behind.

Over time, as mountaineering technology matured, a new approach to passing the Death Zone emerged—supplemental oxygen. With supplemental oxygen, there is a lot less strain on the human body to perform at extreme elevation. With supplemental oxygen, not as much preparation is required for entering the Death Zone and staying there longer is not nearly as dangerous. Less-experienced climbers may attempt summits previously thought unthinkable, while not having to consent to extreme risks or rely on extreme luck.

Enter VC funding. A company that convinces a venture capitalist to make that leap of faith required to get from "we think we found a have a product-market fit" to running a real business, proceeds to raise a series A. With the extra money, the company tries scaling and flaring its model quicker and hotter. The money also allows the company to remain in the Death Zone much longer, and to enter less prepared. It's even possible to go through fundamental changes in business direction while in the Death Zone, and still reach a successful exit. But, just like with oxygen in the mountaineering Death Zone, startup disasters become much larger at scale, more unpredictable, and more sudden. They affect not just the "experts" but also the unsuspecting “tourists”, and often to a higher degree.

Death Zone-related tragic events actually happened in both mountaineering and business. In 1996, eight mountaineers died climbing mount Everest, largely because of what amounted to recklessness allowed by supplemental oxygen. In the dot-com bubble, the Death Zone funding supply extended into public markets, with disastrous effects. Both events were much reflected upon; systemic changes were called for in both industries.

While it is impossible to add supplemental oxygen to an ongoing climbing expedition in any amount that will allow it to achieve “unplanned” success, like going to a higher summit, it is very much possible with venture funding. Otherwise successful companies that execute exceptionally well against their planned climb are seduced to load up on oxygen, gather "tourists", and keep heading deeper into the Death Zone, in search of that elusive higher mountain.

Announcing Mattermost Integration

By Andrei Soroker

Mattermost is a open source team chat service that’s compatible with Slack’s API and is trivial to self-host.

I’m happy to announce that Sameroom now integrates with Mattermost, which enables Mattermost users to share channels not only with 20+ other services, but also with channels in other Mattermost instances.

Below is a copy of the announcement post I guest-wrote on the official Mattermost blog.

My name is Andrei—I run Sameroom, where we make chat interoperability easy. I’m excited to announce the integration of Mattermost with, allowing users of the open-source Slack alternative to connect to 21 different messengers, including Slack, Skype, and HipChat.

Let’s take a step back for a brief survey of the current business chat landscape—I’ll show why cross-platform and cross-instance interoperability is an important stepping stone in making chat a viable model for external communication.

Team chat has long been the internal collaboration approach of choice for technical teams. Traditionally, these teams have been small, closely-knit units within large organizations. Since corporate IT rarely, if ever, offered team chat as approved technology, each unit chose its own platform and used it under the radar.

After decades of quiet, the word got out. The number of team chat solutions mushroomed, seemingly overnight. VC and corporate investment in the space jumped from virtually zero to billions. The New York Times and The Economist announced the end of email.

Small, closely-knit teams, accustomed to email for anything external, began getting invites to other units’ collaboration solutions. There was excitement—they were right all along!—but also a feeling of the implacable undoing of everything that was right in the world.

Unlike email servers, various team chat services, and even isolated instances of the same type of service, generally don’t know how to work together—there is no “universal ether”, a protocol similar to SMTP, for chat. XMPP was a solid attempt at one, but it didn’t work out.

Lack of cross-team and cross-platform interoperability results in two fundamental problems. The first problem has to do with compliance—most corporate policies require all company-related communication to be retained on company-owned systems. Therefore, for every “guest access” scenario, one of the sides invariably violates its corporate policy.

The second problem is account creep—if, for every external project, every person in a tightly-knit team has to create and maintain another account that has to be monitored on desktop and mobile, it’s easy to see that this approach doesn’t scale.

We built Sameroom to fix these two problems. Sameroom makes it easy to create real-time, 2-way bridges (we call them “tubes”) between chatrooms belonging to different environments.

A tube connects two rooms or channels into a virtual “same room”. Tubes can be arranged in an arbitrary topology. Each room retains its own copy of chat history, making chat-based cross-company communication compliant.


Fig 1. Six chatrooms, all connected into a virtual “same room”.

With Sameroom, account creep doesn’t happen at all: For every external project, a team can designate a channel shared with a channel in the service used by the other party.

Over the past few months, we’ve heard a steadily increasing choir of requests for an integration with Mattermost. Today, we’re happy to announce its general availability.

The integration is full-featured, and is actually superior to Slack’s in one important way: Files appear to be posted from the actual author, not “sameroom”.


Fig 2. Files shared in Slack come from the “sameroom”, with actual author’s name appearing in a comment.


Fig 3. Files shared in Mattermost come from the actual author

In addition to cross-platform integrations, Sameroom makes it easy to share channels between different Mattermost instances—as Mattermost grows in popularity, it’s safe to assume there will be an increased need in Mattermost-to-Mattermost connectivity.

To get started with the Sameroom Mattermost integration, follow this URL:

Announcing GroupMe Integration

By Andrei Soroker

Today we’re happy to announce support for GroupMe as a part of our new set of BridgeBot integrations.

With this integration, it’s easy to sync GroupMe groups with groups/channels/rooms in other collaboration systems (Sameroom supports over 20!).

Connecting to Skype

Let’s take a look at connecting a GroupMe group to a group in Skype.

  1. Select your GroupMe group
  2. Type -sameroom open in your GroupMe group. (Wait for the BridgeBot to respond with a code.)
  3. Add to your Skype contacts
  4. Invite Sameroom Bot to your Skype group
  5. Type -sameroom connect <code>, with code from step 3 above.

This will create a 2-way, real-time Tube between the two groups. For more info, post -sameroom help in either group.

Connecting to Slack

Slack is an example of a service without a BridgeBot: You’ll have to add your Slack account to Sameroom (part of step 3, below).

  1. Select your GroupMe group
  2. Type -sameroom portal (Wait for the BridgeBot to respond with a Portal URL.)
  3. Navigate to the Portal URL and follow instructions.

If you have any questions, please contact us or send us a tweet.