I’m all for chat. How large of a project would this truly be? I recently threw a project on freelancer.com 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 freelancer.com or similar site. Done.
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 freelancer.com, 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.
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.
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.
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…
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.
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.
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.
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).
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…
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.
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.
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.