Planga: Seamless Chat Integration Service

Chat / Discussions
, , , ,
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: .

13 Likes
2

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

2 Likes
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:

3 Likes
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!

2 Likes
5

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

1 Like
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.
1 Like
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:

2 Likes
8

Last week was spent mostly on improving documentation and making the basic CSS-style that is being used by default nicer and more idiomatic. Also, the Ruby-gem now is fully tested, with the rest of the app soon to follow.

2 Likes
9

I’m also working on a similar service where I’m writing moderation logic. And actually a few levels of user hierarchy.

Have you come up with your own solutions for this yet? Are you using Phoenix? What about spam detection/prevention - any ideas on that topic?

1 Like
10

I haven’t come up with anything yet, the furthest I’ve gone so far is starting on a project that records the goings on in the network. This is called Raisin (to fit with the theme of Grapevine, another project.) It’s a phoenix app that connects to the Gossip network has a privileged application to get a super powered socket.

This project for reasons of extremely low usage at the moment can get away with ignoring certain things like spam detection for a pretty long while I think. Not too many people play text based games after all! :smile:

The most I’ve done for moderation at the moment is try to spell out all the ways the network might be moderated and see what the community thinks. Moderation · Issue #30 · oestrich/grapevine · GitHub

11

Ok thanks, your project looks interesting!

My thinking for moderation is like @Qqwy 's idea #2 - basically user’s occupy different privileges which allow them to do stuff. Spam protection I’m thinking about simply spinning up a new process per each connection to monitor it. Either that or do something simpler with socket.assigns .

Anyway, congrats for your Planga project launch! Sounds like there’s a good need for a service like this.

1 Like
12

Thank you! :smiley:

Another thing we are in the process of implementing is to include a rate-limiter that will both on a per-user and per-IP basis reject it when ridiculous amounts of requests are done in a short timespan.

This will not prevent all spam, but will prevent the most common primitive ways of spamming the system.

13

Another thing we are in the process of implementing is to include a rate-limiter that will both on a per-user and per-IP basis reject it when ridiculous amounts of requests are done in a short timespan.

Oh but that will be amazing! Are you working on that in the open source repo as well? I’ve been thinking about ways to implement such a system too (but mainly for Channels), do you intend to cover Phoenix’s Channels as well with it?

14

Yes, that will be part of the open-source code, and yes, it will be called from the Phoenix channel, which currently is the main way to send messages. :slight_smile:

1 Like
15

The project is going strong!

During the Groningen Ruby+Elixir-meetup, I gave a presentation on how we’ve built things, especially on how the communication between the partial Ruby interface and the actual chat-application written in Elixir is done. For who’s interested, the presentation can be found here

Also, we’ve just published a guide on how to use Planga in your Elixir/Phoenix-application:

https://medium.com/@W_Mcode/setting-up-simple-live-chat-in-a-phoenix-project-using-planga-3bb254b2261b

4 Likes