Chat Plugin features


I’m all for chat. How large of a project would this truly be? I recently threw a project on for a ground up build of chat which integrates into discourse database and has the same look/feel as it. Offers were in the $300-400 range.

I’ll assume this would be more for a straight plugin, but no too ridiculously much. Is $500 a reasonable assumption?

At 63 votes, I bet you could get 100 individuals to throw in $5 a pop. There’s your monies to get it done. All that would be needed is a little organization to get 100 people to throw into the pot. Push it on or similar site. Done.

Big Picture Features Poll
What is the most awesome plugin for Discourse, that does not yet exist?
(Kane York) #2

A few cursory investigations have concluded that the problem is mostly the UI work. Where do you put it, what does it look like?


Ok, except I’m not a developer in the slightest. Guess what I’m asking is, how many (wo)man*hrs… monies do you think this would take?

Personally, I’d like to see it as a section of the screen you could hover over, and it would expand out. Pick a close to the corner edge spot.

It would also be nice to have reverse infinite scrolling. You see the posts that show after the bubble expands out, yet can seek back as you wish to the beginning of time.

I’d also think it clever to have an easy hotkey for it. A chime + flash to indicate a msg ur wave, hit the hotkey to expand out the chat.


I’ve decided to take the initiative here. I’m certain that a lack of chat is keeping this community from becoming that next-gen platform people don’t even know they want yet. There’s interest in chat, but it seems scattered enough as to never be hashed out and really thrown the energies needed to see it through.

What I’m going to do is front the monies for the plugin to be developed. We need to come up with the best UI, then I’ll relay this to developers on, and pick the best one with a reasonable bid. I’ll then seek small donations to recoup the cost. You throw $5 for the plugin, I provide the download link. After funds have been recouped, it’s free for all.

Sound reasonable?

This thread is now for ideas on the UI, and features for chat. Mockups are welcome. Practical application from ruby developers is welcome. I’d like to hear ideas for a week, then pitch the best ones for development. That means we could have chat by mid February.


Just make sure you’re not falling foul of the Discourse licensing terms. I don’t think you would be, but here’s an example term that might cause you trouble:


Thanks. I’ll be sure to run this by the developers. I will not make any monies off this.


From my reading of the license, I think plugins are okay if they’re distributed separately, but you should definitely seek confirmation.

(Tobias Eigen) #8

You could also look for someone here in the marketplace category to build this, who already knows discourse and it’s extendability model. Please do develop it under the same open source license. I might throw some money into the pot if the plan is credible.

(Benjamin Kampmann) #9

We are currently implementing Chat for Discourse as a separated service (with XMPP, so that you could also connect to the instance from an external app without being on the website at all) and my brain hurts on where to put it in the UI and which features to support and in which order: one-on-one, one-to-many and rooms? The current plan is to do one-on-one and a community-wide room first, the rest later.

But UI-wise I am still confused, where and how to do it. My current thinking is do the chat-windows in facebook-style (with the username from the bottom) and conversation-creation by having a chat-bubble somewhere (in the top-right menu bar maybe?). But I am not happy with that.

Do you have some proposal/idea on where to put it (maybe even a Mockup)? The bottom right is kinda blocked with the ugly progress-bar-button…


I posted my idea here

It was a chat icon to the left of the PM bubble at the top left accessible drop down via click, else g , 1 hotkey. also a floating window accessible via g , 2 hotkey.

I specified this to be fully integrated with identical feel/look, guy said no issue. He’ll code it in ember. Did not mention the XMPP. That would be nice, but not necessary, imo.

$800 the developer wants. I have 24hrs to decide.

I chat with developer. He says XMPP can be added for $1000 total price now. Wondering how far along you are with your project, eta for completion, etc… would rather not compete if you’re far along. Wait for you. If not, going for it.

(Benjamin Kampmann) #11

That was also my first idea. It could flap out and have two main features: the listing with all recent conversations and b) a way to autocomplete the name of another person you’d like to chat with. The question for me becomes then, where do you put the conversation window?

Not sure what you mean by that. Do you mean an overlay modal that’ll contain the conversations? I’d really like to keep the UI somewhere off the main-land. It is very likely that I am waiting for the user to reply and want to browse around the community more. I really like how the composer – in a way – is not very intrusive and I think we should do the same for a chat feature. Think of bottom-bound facebook or google-hangouts chat boxes.

Having implemented real time messaging twice before, I can tell you instant messaging is quite a complex problem to get right. On both accounts the UI (as mentioned previously) but more so on the backend infrastructure and the protocols used. Sure, it is possible to put something up that kinda works based on some self-baked protocol using node or polling for a tiny budget.

I and @anouk were also playing around with building our own solution but you quickly encounter problems like sessions and presence management (aka “who’s there and are you still online?”) or how to deal with offline-messages. That already becomes complex quickly, leads to weird bugs and eats up development days. And I haven’t even started thinking about multi-user-chat or being able to block spammers and abusers. The funny thing is, all these problems – among 350 other ones – have already been solved in XMPP/Jabber for years and there are plenty of proven open source solutions for it. Don’t reinvent the wheel…

So, clearly using an existing XMPP server as the backbone and only build your own specific stuff (like on-site-presence ) on top is the way to go. But running a proper system, either your own or a jabber-server, means yet another system to keep up to date, maintain and take care of. As we’ve seen in the past (for example with tagger), building the initial version isn’t that hard, but keeping a plugin up to date with latest changes and continuously improve and bugfix it, is the big challenge and needs to be taken into account when building something like this. Chat is much bigger and much more complex of a problem than tagging.

Both of these challenges convinced us to build chat as part of an open-source solution that we will also offer professional, hosted support for (for a small fee). Allowing us to ensure that the service is administered properly while also continuously improve upon it. Of course, you’d still be able to run your own server, but then it is up to you to take care of it.

We have the backbone in place, up and running already. Our main concern lies with the UI and some additional features at the moment. That’s also why I was asking for feedback about this earlier (and inspired by you, will open a discussion about it). Our current plan is to have a first closed beta starting mid February with a more or less complete UI, depending on how far we can get the discussion before.

If you or anyone else are interested in being part of that beta, just send me a PM, referencing this conversation and with some brief info about your community (url, size, focus of discussion, etc). I’ll gladly get back to you about it.

What should on-site chat look like?

Well you’ve convinced me this should be handled by someone who can continue to develop/update as need be over time. What I wanted more than anything was sustained attention to push someone to develop it, and if that didn’t seem possible, to hire a developer. It seems you’ve already realized the importance of chat, and are putting a good deal of energies towards it. Awesome! Go for it, I’ll tell the developer the project is not going to happen. No worries.

As for the second hotkey, my thought was to have a detached window for chat in order to overcome the potential clutter issue. You and others have mentioned the inability to clearly decide where chat should go. The solution seems obvious, force it where it isn’t ideal on screen, then have the option to hotkey onto a new window independent of that potential for clutter. So let’s say you already had the scroll down of chat. If you hit the second hotkey, the drop down disappears, as the second layer/window pops up.

I’m not a developer. Excuse my bad wording. I may be using terminology incorrectly and causing a bit of confusion. Just waking up. May need to edit this post here in a bit.

(Erick Guan) #13

XMPP consumes much bandwidth. It’s well designed but it seems a little of age.

(Sam Saffron) #14

I just don’t understand why not use the infrastructure that is already in place. GitHub - SamSaffron/message_bus: A reliable and robust messaging bus for Ruby and Rack

(mountain) #15

That is an interesting question.

Pinging @lightyear.

Does the message bus basically use Discourse for all the things XMPP is suppose to do? Like for spam/abuse? I am guessing small flags can be put next to each chat message to flag a message (same as a forum post).

(Benjamin Kampmann) #16

Exactly, what I am saying: why not use the protocol if it’s already there?
I am really no big fan of everyone coming up with their own chat-implementation on their website. We have open, proven protocols, that are working fine in the world for ages.

Specifically for our use-case, a message-bus driven message-delivery simply isn’t enough. We are running our team communication through Discourse, it has replaced email for any internal communication. But for real-time communication and quick discussions, DC isn’t usable. So we end up with a skype chat here, a google hangout there and occasional IRC-chats – it’s a mess. One key thing about all of them is, though, that you have them readily available on any device (including mobile) even when the person is out in the field.

We were considering using something like Slack to do that. But aside from not liking their lock-in too much, keeping the group-administration and everything in two places just is annoying (as we have very fluid groups). All I really need is a DC-managed XMPP-Server, as XMPP offers all of that from right from the start. Having a chat-interface within DC – for us – is just a nicety on-top to also connect the more casually joining people as well as (random) community members.

On top of that, I do like the federation-part of XMPP very much. I don’t like that more and more of communication ends up in the silos of Facebook, Google and Whatsapp. Having an XMPP-Account on your local Community-DC, you could open that server to allow for federated messages from other communities – still receiving the messages on your community. I think this both great as it takes back the decentralized approach the internet should have, as well as allows for easy connection of communities across the boarders of DC itself. And all of that comes for free, as it is build into the protocol.

No. The message bus is merely a delivery technology to get live updates from DC to the client (like when new posts appear in the topic you are on, that’s been done using the message bus).

In comparison to what? Can you name any other open Instant-Messaging (not message-passing) protocol that offers above mentioned features?

If you compare it to other general purpose messaging technology (without presence at all) like ZeroMQ, AMQ or MQTT, then yes, it does have more overhead. And in those cases (same for the mentioned message bus), you’d still have to implement all features yourself, even the most basic ones like presence. Question of trade-offs…

And, then, XMPP is still good enough (on bandwidth) to run WhatsApp on it, so …!?!

(Sam Saffron) #17

Why not? because now you have a huge problem of distribution, how are you going to get people to install this thing? They can not just install a plugin, they also need to install an XMPP server, which is complicated.

So you are building an artisan tool for your own internal use, which is fine.

Additionally you are going to need to build complex comms with that server, no chance you will get long polling from the client working. zero chance.

(Benjamin Kampmann) #18

Long polling and HTTP-Binding-technology – called BOSHare part of the XMPP specification since 2003. Server and JavaScript-Implementations are running in production for over ten years . Turnkey Solutions to setup both, your ejabberd with a full-functioning web-chat, are available since 2009. Almost all modern Javascript libs also support the new websockets draft, too.

Setting up an xmpp-web-chat in with strophejs was as much work as changing the server name in the examples.

(Sam Saffron) #19

Using and building on top of the existing infrastructure is not precluding you from implementing an XMPP bridge, or whatever.

This is how I would design this if it were up to me:

  1. Have a special attribute on categories that denotes it to be a “chat” category (advantage, you get all the security stuff totally for free)

  2. On chat categories only the system can create topics, system creates a new “chat log” topic once a day/week/on N messages.

  3. You build a new UI for these chat topics, and reuse the existing post creator etc for posting into it.

  4. If you need XMPP you build a bridge on the server and federate with it, creating posts on Discourse side and mapping users as needed. (people that do not need this can easily opt out)

  5. You add presence channels into message bus.

This design reuses our existing infrastructure nicely, you get security, long polling, search and so on without needing to reinvent or create complicated hooks into the system.

From what I am seeing you are designing a system that is going to be way more complicated to deploy than simply “add a line to your container config” and will not be tightly integrated into Discourse.

(Erlend Sogge Heggen) #20

I actually think both approaches hold equal merit, though @sam’s more integrated chat sounds like it’d fit my particular use case best.

My dream set-up would be to have chatrooms (i.e. chat-categories) for all major development groups involved with the making of our product. Core, UI, Plugins…, similar to WordPress Make. These chat-categories would be connected to their respective equals in Slack Chat Rooms via XMPP or the Slack API.

My go-to client for chatting would still be Slack, but this would be an effective way of bringing new contributors into the conversation, since the forum is already part of their workflow.

In my community, these chatrooms would essentially be an extension of the Lounge, so the attrition-rate would be very manageable and we could rely on manual account set-ups (i.e. invite them to Slack and add their Slack ID to their Discourse profile) instead of API cleverness if necessary.

Particularly appealing if Discourse figures out Group/Category mentions.

The thing about @sam’s outline is that it assumes effortless changes to core. For someone trying to iterate quickly and scratch their own itches I don’t think following the close-to-core recipe is realistic.

These two solutions serve different niches the way I see it.