Planga: Seamless Chat Integration Service

channels
phoenix
websockets
chat
scalability

#1

After a couple of posts teasing at its existence and development, I’m pleased to officially announce our latest project to you:

logo_planga2-with-text-rainbow-black

Planga is a webservice, providing a seamless chat integration to whatever application you are building: Live-chat in one form or another is something that many applications (especially platforms) require, but it is difficult and extremely time-consuming to get it right:

  • Users expect all the features they know from dedicated messaging applications.
  • Users expect it to work flawlessly, regardless of how large the system becomes, intermittent connection problems, etc.

Rather than every platform developer spending a lot of time and resources to build a semi-working solution, we set out to solve this problem for once and for all, by creating a simple-to-use system that uses your user accounts and your way of deciding whom should talk to whom, but otherwise completely gets out of the way of your application, and therefore is scalable.

The technology

The Planga Chat service has been built using Elixir and Phoenix: We use Phoenix channels (using websockets, falling back to longpolling) to connect the browsers from users with each-other.
To persist the chat messages, we are currently using the built-in datastore Mnesia, although we are in the process of comparing Riak, Cassandra, CouchDB and a few others to find out what would be the best distributed option to move towards once the system starts growing.

The current version of the dashboard where you, as a developer, manage your API keys, was built in Ruby on Rails, mostly because the Ruby language is great for fast prototyping, a larger group of our team had experience with working with Ruby already, and because it is a conceptually simple, replaceable piece of the technology stack.

To keep the chat as scalable as possible, your application only sends configuration (what is the user in this browser connection’s ID, name and what chat channel is he/she allowed to connect to?) to the user’s browser on page load. After this, all communication happens between the user’s browser and Planga’s chat server.

To make this secure, this configuration information is of course sent encrypted (using the JOSE-JWE encryption suite).

Because the communication has been set up in this way, your application only has to care about sending the configuration to the browser (and we are releasing a slew of language integration libraries to make this even simpler).

Open-Source

We want to give back to the community, and we do not believe in ‘black box’ solutions: If anyone is able to inspect your work, it is a lot easier to find out how it could be improved. And besides this, of course not everyone is comfortable with sharing their user’s data.

And this is why we are releasing the Planga Chat application as an open-source project. (Of course, if you decide to use our service, we will be able to manage scalability-issues for you, as well as being able to provide a set of extra features that are difficult to provide on a self-hosted system, but the core application is and will always remain free!)

The Future

What we are releasing right now, is the initial Beta-version of Planga. In the spirit of the Agile Manifesto, this version is very basic. We have a lot of ideas for functionality that could be added, but first we want to start interacting with you, the potential user of the system, and find out what you want!

Please, ask all your questions and be honest with your criticisms! We would love to hear your unfiltered opinions about his project to continuously make it better :slight_smile: .


What Elixir related stuff are you doing?
Ecto-less migrations?
#2

Nice work, love it! The website is a little pink though.


#3

Nice one, congrats Qqwy!

I love the colour - in fact I’ve already been working on something that has a very similar colour :003:


#4

I started a similar service but for games a while ago, I’d be interested in seeing how you deal with moderation. Maybe we could come up with some common tools.

I’ll definitely be perusing the code!


#5

This is great, good work and congratulations! :slight_smile:


#6

Good question! Of course, how moderation should work exactly greatly depends from application to application.

There are three possibilities currently on our mind (and we are open for other ideas as well, of course!):

  1. Automatic tagging of message intent. While this does not prevent all kinds of bad activity, it does filter a lot of malicious, harassing or otherwise spammy messages from appearing at all.
  2. The possibility for certain users to be given ‘superuser’ accounts, which are able to edit/delete messages written by other users.
  3. (Related to (2)). The possibility to hide messages by users who have, in the meantime, been indicated as ‘deleted’ by your application.

#7

Last week has been spent mostly improving the documentation of the various language integration packages we’ve made so far, as well as on Planga’s website itself.

Also, quite some effort has been spent in refactoring the Phoenix application that runs Planga. Only slightly more work needs to be done to make the database swappable, and then it’s time to add a rigorous testing suite!

Please let us know what you think of the current documentation and explanations. Are they clear? Is the language we use understandable? :slight_smile: