Slack has gained a lot of popularity in recent times as a tool for inter-team communication and for the right reasons. It offers a lot of features such as 3rd party software integrations, rich content communication, collaboration, bots etc. which when put together help create a rich collaborative user experience for teams to work together, especially when they are not co-located, which is fairly common these days.
If you’re anything like me and have been around long enough to know what irc is and when you look at various elements that slack provides like channels, accounts (servers), private messaging, etc. you know that it draws a lot of parallels and inspiration from that old school communication tool.
However, slacks desktop application, which is build using electron, although is very feature rich, is extremely memory hungry for my liking. I have also experienced extreme slow downs / hang ups at times. For that reason, I have always been on the look out for a way to combine the rich user experience of slack with the simplicity of irc without compromising a lot on the goodness the app provides.
Slack has always offered an IRC gateway which can be enabled by a team admin, and then you can use any regular irc client to connect. However that means that I have to compromise on a lot of features, some very basic such as editing your own messages etc and also since it needs to be enabled explicitly by an admin, its not always available.
Recently I came across wee-slack which is a slack app built as a weechat plugin.
Since I had been using weechat already previously as my irc client (still do), this was perfect for me. After using it for a significant amount of time, I can say it is superb. It gives me the best of both worlds without compromise. It uses slack’s APIs and hence does not require an explicit IRC gateway feature to be enabled by an admin, moreover it gives a very text friendly API to leverage slacks features from within weechat. I would highly recommend using it as opposed to using the slack app since it is extremely light weight yet powerful.
WebRTC is fun! I recently gave a quick session on WebRTC at Bangalore Ruby User Group (BRUG). Following are the slides of my presentation.
For demo I had recently created a demo application in elixir using the phoenix framework because it makes dealing with websockets really easy. That is used for creating the custom signaling service that is required to facilitate such a broadcast. The source code is available at dhruvasagar/webrtc-broadcast
In a nutshell for the purpose of a demo, what I essentially do is that each ‘Host’ (who access the home page at ‘/’) sends out a ‘stream-ready’ event notifying that it’s stream is ready to be shared and that is then communicated to all other hosts. This then lets them initiate the basic WebRTC signaling that’s required for them to know about each others’ audio / video capabilities by means of the offer / answer mechanism. Once that is complete, they finally receive each others’ streams and that is then added onto their views dynamically.
For listeners (who simply receive the streams, and are not required to share their streams, access the site at ‘/radio’), they initiate the process by sending out a ‘stream-request’, which the signaling server then passes forward to all hosts. Once the hosts receive the ‘stream-request’ they follow that by initiating the WebRTC signaling process for communicating their streams with the listeners (by means of offer / answer). Once the communication is established the listeners then receive the streams of all the hosts and add those dynamically to their view.
I wanted to demonstrate that once you understand the process of facilitating an offer / answer to establish the initial connection between two peers using RTCPeerConnection, rest of signaling can then be customised as per situation to facilitate any kind of complex multi peer-peer communication.
NOTE: In this demo, a broadcast implies that each host shares his stream directly with each listener. So as the number of listeners (or hosts) grow, the number of peer connections required also grows rapidly. From the perspective of achieving a scalable broadcast service (peer-peer), it may instead be better to utilise each listener to also act as a proxy host, allowing for him to be able to share the stream of other hosts to other listeners, reducing the overhead on the hosts and also reducing their bandwidth requirements.