Speccing out a full page chat plugin

‘4’ and ‘5’ are both on the very top of my Discourse chat wishlist, but I don’t think they’re critical for a v1.0. If anything, ‘5’ should come before ‘4’.

meta.discourse.org is the most natural place to test the prototype of such a chat (as we did with Babble), and the sub-community most amenable to chat in Meta is the #lounge (which I think should be expanded to include user types like serial contributors, but that’s a different topic). And all we need for that is one chatroom. I hope we can agree that this is the MVP.

Will gladly talk through these other designs on the side though!

Agreed. Linking to tags could get hairy though so I think “all categories” and “individual categories” would be best for starters. DropBox’s Zulip chat app has an interesting concept of “threaded group conversations”, and it’s not the scary kind of threading that we Discoursians despise:

I don’t have a perfect solution in mind yet, but I definitely think this is a solvable problem. That being said, figuring out ways to incorporate tag/topic-specific discussions is “next-gen” territory as far as I’m concerned.

I think Facebook Messages is a great example of a chat/pm hybrid.

It’s always the same conversation, but in different gears. And when a user is posting a series of uninterrupted replies, maybe we could automatically merge them together.

Discourse PMs are already super powerful; they’re basically what I always wanted Google Wave to be. I’m not keen on adding a competing conversation stream into the mix. All we need is a few more “live” features built into PMs, like presence info and opt-in quick-reply.


Right, so the mvp would include the following:

  1. A chat topic type. Personally, I think we should add a new Topic Archetype: chat, adding to the existing archetypes: regular, private_message and banner. A significant difference in the backend between Babble and Quick Messages is that @gdpelican has created a more custom topic and post architecture, whereas I have largely used the existing architecture and just distinguished quick messages from normal private messages via a custom_field. Neither of us took the route of adding a new topic archetype, but considering that we may want this chat plugin to integrate closely with various pieces of existing Discourse logic, I think a new archetype is the way to go. Before we start we should sort out our thinking here. Some notes about the chat topic archetype:
  • It will need to be entirely excluded from discovery streams and normal topic view.
  • There will need to a restriction on how many can be created for each category (i.e. 1).
  1. An auto-sizing single line composer with emoji, markdown and support for attaching pictures. This could be either component-based (quick messages) or widget-based (babble). This is relatively plug and play from our existing work.

  2. Override the default rate limiter for posts in chat topics. Equivalent code in quick messages. We will need a rate limiter, the question is how low it is set: 1 second?

  3. Remove or significantly increase the time-based limits for posts in chat topics. Equivalent code in quick messages. Do we want any time-base limits on chat messages?

  4. Remove or significantly reduce the maximum length for posts in chat topics. Equivalent code in quick messages. This is a key difference between chat and long form discussion. Personally, I don’t think there should be any length requirement for chat posts.

  5. Remove or alter the check for duplicate content for posts in chat topics. Equivalent code in quick messages.

  6. Remove or alter the check for whether the post content is sufficiently ‘descriptive’ (I haven’t done this in quick messages). Discourse code.

  7. A widget-based (babble) or component-based (quick messages) post stream. Both Babble and Quick Messages use the existing postStream model for topics. This is relatively plug and play from our existing work.

  8. Post actions on posts in the chat postStream: edit and delete. This exists in widget form in Babble. If we go the component route, it should be relatively easy to create equivalent components that leverage the existing postStream functionality.

  9. Add a new category sub-route for chat, toggled by a setting in the category settings. User access to this route would be via a button in the category discovery UI. Like Unread, the button would include the number of unread chat messages.

  10. Tweak the notifications produced by the chat topic to:

  • Visually distinguish them for the user
  • Route the user to the right place (i.e. the category chat stream rather than a topic).
  1. Prevent chat topics from producing email alerts. While we may want to add email alerts about chat in later versions, they should probably be entirely occluded for the MVP.

I agree. I basically copied Facebook Messages’ approach for quick messages, however I focused on the message menu and pop-up chat-boxes. For this plugin we could start with the full page part of Facebook Messages and perhaps add the menu and pop-up chat-boxes later. In terms of the MVP I’m thinking that we should not include any private chat work.


I’ve gotten a bit of a start on this, which is up on the full-page-chat branch on the babble repo.

Here is a screenshot: (it’s not that pretty yet :dancer:)

In response to the MVP prompts:

  1. A chat topic type: I’m happy to move to a ‘chat’ archetype if it’s necessary.
  2. Autosizing single line composer: This is done with the exception of adding uploads. Uploads may be out of scope for this MVP, but would be happy to have them again.
  3. Override default rate limiter: Babble ignores rate limits at the moment, so we’ll want to put one in there. One per second sounds good.
  4. Remove or significantly increate time-based limits for posts: We’ll have to add this (if we can repro it happening)… I’m surprised I never heard feedback about this one, actually.
  5. Remove or significantly reduce the maximum length for posts in chat topics: This should be easy to add
  6. Remove check for duplicate content: Babble does this
  7. Remove or alter check for ‘descriptive’ posts: Babble does this
  8. A post stream: I think the post stream is Good Enough for this iteration (although things will get hairy around searching through history and such, and we will likely want to revisit it at some point)
  9. Post edit and delete: These work for Babble
  10. Add category sub-route: I think I agree with this approach, but wonder about the unread count (does it just show the unread count for the selected chat? With Slack it’s a single dot, essentially saying ‘there is stuff to read here’)
  11. Tweak notifications produced by chat: Yes. I’m not quite sure how to do this yet, but we’ll want to do it somehow.
  12. Prevent chat topics from producing email alerts: Babble doesn’t currently send emails about chat.

From my end, my checklist looks like:

  1. Make existing widgets flexible enough to appear in shoutbox and full page chat (done)
  2. Add routing and views for a full page chat (done)
  3. Add site settings to allow users to enabled/disable both the shoutbox view and the full page view
  4. Add a ‘who’s in the room’ function to show who’s currently viewing the chat (which will appear underneath the channels list, similar to slack’s layout. Eventually we will make it so that you can send private / quick messages this way.)
  5. Style up everything so it looks good and is responsive
  6. Add a default ‘lounge’ chat channel (since that’s our stated MVP per @erlend_sh)
  7. Figure out where to expose the route to /chat in the UI, and how notifications will work

Sweet! Sorry for being absent here. I was in DC, then my dad was in NYC so I was showing him around etcetera etcetera… Will get cracking on working-in with you presently.


I’d like to test a chat on my community. People ask me about it every day!

1 Like

Sorry for the delay on this folks; Angus and I are both working on other sweet Discourse things at the moment, but we’ll get back on this train soon!


@gdpelican I just pushed a new Babble branch full-page-chat-discovery to demonstrate how I’m thinking on how the frontend should work.

I think that, rather than having a completely separate view, the chat stream should exist as a sub-route of Discovery, taking advantage of the Discovery navigation, rather than using ‘channels’ per se.

Screencast of functionality: http://quick.as/R0YoIav2e

I’ve also added some updates to Admin Chats to allow the selection of categories to create new chat topics in.

As you can see, this has required a few changes, which is why I’ve pushed this to a branch so we can discuss.

Here are some of the salient differences:

  1. Client side chat routes are mapped to discovery, and follow the pattern of the build-category-route component to pull the appropriate Babble topic and render the appropriate templates in the Discovery outlets. The individual routes are built in this initializer (copied from the tagging plugin).

  2. Chat admin gets a custom category dropdown to allow new babble topics to be created in different categories

  3. I’ve added in the ‘chat’ topic archetype, because I think this makes it easier for us to link chat topics to categories, using the archetype to differentiate them, rather than the Babble category.

Concerning your remaining todos, ‘6’ and ‘7’ should be covered if we go with my suggested approach. I’ll start tackling ‘5’ (as it will be the same regardless of what approach we take) on the weekend.

Let’s finish off this structural question and your to dos first, then we can see if anything needs to be done with rate limiting and other limits. We can probably just copy these from Quick Messages.


Really excited about this. Do you think having the chat live on the bottom right of the screen where there is a lot of space would be possible?

1 Like

Sweet! I have this on my list for tomorrow. :dragon:

This is awesome work, thanks! Some thoughts:

  • I wondered while playing about the way we differentiate between a ‘category’ and a ‘group’ chat. Here’s a quick mockup for something that feels intuitive to me:

Group chat:

Category chat:

  • ‘Chat’ archetype seems simple and cool. Does this mean that topics won’t appear in the topics list anymore for admins?
  • The chat button on a category seems like a great way to get into the full page chat; we’ll want a way to swap between chats once there though. I’ll have a play today to see what I can come up with there.

Cool. So there’d be one type of ‘create chat’, then within the view for the new chat you could set the permissions, name and groups?

Does this mean that topics won’t appear in the topics list anymore for admins?

Not by default. But there are a few ways we can exclude both I believe. I will look at this shortly.

I’m updating the chat UI itself at the moment.

If you’re cool with the general direction, let’s merge full-page-chat-discovery into full-page-chat.


Any updates coming soon? Is it safe to implement on my site yet?

Not yet. Both Angus and I have been contracted for other Discourse work over the past bit, so this hasn’t surfaced yet.

We are meeting up tomorrow for a hack day on this, so hoping to have a solid update then.


Looking forward to this guys :smiley: Great work!

@angus and I had a nice time yesterday hacking on this thing; we’re getting close to a first stopping point, after which we’ll encourage folks to install it and play around a little. Here’s a gif of the existing functionality:

Creating a category chat

Having a chat in full page mode

We’ve also added a site setting which allows toggling between full page mode and the shoutbox style plugin which exists currently.

If you really want to be on the bleeding edge, you can follow along with the following clone url:

git clone -b full-page-chat https://github.com/gdpelican/babble.git

And select ‘enable full page chat mode’ in the plugin settings.

But I couldn’t recommend throwing this onto a live instance just yet.


I approve this message :slight_smile:

I would add that we have a basic plan for the rollout of all the features previously discussed in this thread, and even some not yet discussed, such as import from Slack.

We’ll be releasing the MVP soon.


Zulip chat app has an interesting concept of “threaded group conversations”

Another interesting example of this can be found in we-hate-distractions.com which takes a topic-centric approach to group chat.

Just putting it out there for inspiration.

Aha 750$ per month for a local redit ^^ :joy:

Alright, I’m ready to open this up to beta testing. If you’d like to have a play, go here:


And let me know what you find!

Improvements since we last left our heroes:

  • Allowed loading of chat history
  • Removed duplicate avatars and timestamps for messages which are sent close together
  • Mentioning works!
  • Link unfurling works!
  • Added date separators
  • Logged out users can view chats (if they have permission)
  • The whole thing is faster!
  • Chat activity no longer clogs up your user activity page

‘Who is typing’ is complete pending a PR to the Discourse core repo: