||1 year ago|
|ejabberd||1 year ago|
|nginx||1 year ago|
|www||1 year ago|
|LICENSE||1 year ago|
|README.md||1 year ago|
Chinwag Messaging Setup
This is a collection of config examples and support scripts for Chinwag's XMPP-based messaging service provided for our Mastodon users which can be used as an example by other instance admins to get their service running. These files are pretty close to the live config on chinwag.org but are not 100% the actual deployed scripts and configs, due to the need to redact information like service passwords. Some extra comments and annotations have been made.
Please see the wiki for specifics on getting things set up.
These are intended for use with our Mastodon external auth script as the sole source of user account data, they may not be a terribly useful reference for a general ejabberd deployment but if they help someone out, that's great!
Efforts will be made to update them as changes to the service are made. Enhancements and fixes are definitely welcomed if you spot issues - please submit a PR with your suggestions for discussion.
Current chinwag.org Standards Compliance
Chinwag Deployment Details
Chinwag Social's systems currently run on a base of Debian 10, with Postgresql 11 and ejabberd 20.12 from the buster-backports repository. Scripts and configuration files haven't been tested with earlier or later versions of much of this, but should be broadly applicable if things aren't too out of date.
The core systems may be updated to Debian 11 and/or Postgresql 13 during the course of 2021, but this isn't expected to change things very much. Feedback from anyone using different versions of the core software would be great to hear about.
In the medium to long term, I'd like the service a little better integrated on the Mastodon side, but I have no real clue about working with Ruby right now. Here are some items on the wishlist.
- The Mastodon user preferences should allow the user to activate/deactivate messaging services, so it's completely off if someone does not want it. Right now the user is "created" on first use, but there's no way to kind of destroy the ejabberd user again afterwards if it's no longer required.
- Rather than use the Mastodon password, allow (require?) setting of a secondary application password via user preferences in a separate table and use that. Could also be used for multiple passwords, per device and permit granular revokation of a single device's access.
- Can the JSXC project's authentication hub project or similar be applied here for a web chat client authenticated from the current logged-in Mastodon user?
- Pre-configured mobile and/or desktop app. Fork/embed a project like JSXC or ConverseJS? It'd be nice to provide a reference client to be able to simply document "how to chat" for new users.