Add support for Slack Socket Mode

[chi-block]

Since Real Time Messaging API is not usable in new Slack apps, will the Socket Mode be supported in the future?

[dblock]

It sure can. Please contribute!

[gmhawash]

@dblock Slack Socket mode does not appear to give an equivalent functionality to what RTM used to do. With RTM, I had a production, staging and preview servers, and each used RTM to monitor a single channel. When a message was typed in that channel ALL of these clients received the message, and one of them handles the message based on a prefix in the message .production {command}, .staging {command}, or .preview {command}. With Socket mode, I have a similar setup with a client in each environment, but it looks like a message is only sent to ONE server, and not to ALL. Is there a way to get socket mode to broadcast to all listners, rather than select one of them?

[dblock]

@gmhawash I've never used Slack socket mode, sorry :(

[chrisbloom7]

@gmhawash I'm not an expert on socket mode by any means, but I think the answer to your question is no. You can have multiple connections over socket mode for resiliency, but only one connection will be sent any given message.

https://api.slack.com/apis/connections/socket-implement#connections

[chrisbloom7]

To the more general issue, socket mode is supported in the sense that the client implements apps_connections_open which will return a temporary socket mode URL (api docs) which you can then connect to to monitor for new messages. How you make that connection and what you do with those messages will be entirely app dependent. Here's an example that uses Async::Websockets https://gist.github.com/chrisbloom7/52bc954b4df09b9cb829a73cfd5466c0

[gmhawash]

@chrisbloom7 thanks. It appears that the old RTM broadcast ability is not supported and that SocketMode only supports the ability for scalability or resiliency, where you can setup multiple listeners and one of them will get the message. I had relied on the old RTM broadcast for my implementation, now I might have to implement an app for each environment.

[dblock]

For this library for socket mode support we'd want a higher level events handling interface where you can register events and they get routed automatically.

[ook]

Hi @dblock and @chrisbloom7 , I'm considering adding websocket support to slack-ruby-client. Would you prefer a support based on event-machine or on async gems? Some other requirements on your side? Thank you.

[dblock]

I would say async. It's used in https://github.com/slack-ruby/slack-ruby-bot-server-rtm.

I would look into not bolting something into this library though, because you don't want to drag async into applications that only use web APIs. Maybe a new slack-ruby-client-sockets lib?

[ook]

@dblock deal. I'll mimic web implementation as far as I'll could.