Coupling Discourse with Chat and Cloud

Following a question from @debryc here this is a brief note about some work we have done to get our Discourse forums playing together nicely with cloud storage (a NextCloud instance) and chat (Mattermost in our case).

A long post so lets hide the details till you click the arrow…

Full lengthy post

I should start by stress that I am not the developer of this system - it has been produced in C#/.NET by another member of the Tech team so I can’t answer detailed technical questions on it. I’m just setting out the problem(s) we wanted to solve and what we’ve done.

Background: We had been using an integrated system (Basecamp) for providing discussion, real-time chat and file storage integration. There where many unsatisfactory elements of this, both structural and security so we decided to migrate the organisation to a new open source system/systems.

We did a lot of trawling and evaluation - some of our choices were driven by expediency, others by finding the best match to our requirements and others by the need to make the migration path for 10k users as painless as possible (the users include a high proportion of non-technical and a significant number of techno-phobic users, all with their own strongly held opinions - not easy to please!)

To cut to the chase we settled on three separate components - Mattermost to provide real-time chat, Discourse to provide more considered discussion, and Nextcloud to provide secure file storage and collaborative editing (replacing a combination of native Basecamp storage and googledocs). All our hosted on our own managed servers.

So now we needed to provide a way to stitch the three logins required together in a relatively seamless way and automatically create user accounts and assign users to the appropriate access groups/forums (discourse), shared storage groups (nextcloud) and teams and channels (mattermost).

The organisation has a few hundreds of separate groups/teams (by location and function) and users may belong to many groups - some are closed, some are open for any user to join ad lib.

The first problem was creating user accounts on three systems and initially ensuring that they had the same username (so that they can recognise each other) and password (so that they at least have a single set of credentials to remember/store and ultimately a single signon to all three systems.

We also needed away of managing how to assign people to the correct groups when the account was created - there hadn’t been a good mapping between actual groups and online groups in the old system so we couldn’t simply migrate it.

The solution we came up with was a separate website, called the Hub, which dealt with keeping track of user accounts and using the APIs for the three systems to create and update user details.

The hub also allowed “Tech Champions” for each group (or set of groups) to invite people onto the new services - thus ensuring that only the right people ended up in each place.

So a user gets an invite email to join the new services with a onetime link to the hub where they can create a username and password. This is then used to automatically create corresponding user accounts on the three separate services.

The hub also knows which groups/forums and teams/channels and storage areas the user should have access to and adds them in the relevant places through the APIs.

As it has evolved the hub has had more facilities developed so that now a user can use it to find channels and forums and request to join them and various other admin functions for both tech champions and users.

It can now also provide a form of single-signon, so that by logging in at the hub a user can log in at one of the other services with a single button click. (some of the work here involved excluding the standard corporate social media type logins being used)

We have looked at various ways of integrating chat and handling file storage in a single system (all three make some of this possible), but always they involve massive compromises and you end up with a camel (a horse designed by committee) like Basecamp. Better to stick to a thoroughbred dedicated solution for each of the core functions and have them done well.


Whoa! This is amazing!!! I am really really liking this solution of creating a portal for people to opt-in to different communication channels instead of trying to have one platform do all the things for every function. I’m bookmarking this post so that when, in the future, we may have to solve for the same problem, we’ll have an idea of what’s possible.

On a side note, do you happen to know if this setup can work with Slack and Google Suite (especially Google Groups and Shared Drives?)

1 Like

Thanks for the good words. I totally agree about using different solutions for different requirements. Although when it came to a flexible shared calendar we did settle on the built in Nextcloud one for now.

On those specific apps I don’t know,. It will depend on what API facilities they provide. Commercial software tends to be more limited than FOSS. (and in our case we particularly needed to get off google)