Expand Matrix app features
yusf last edited by yusf
Looking around in the Matrix ecosystem one finds many interesting server extensions. For example, the native protocol bridging support being put to use by the many bridges available.
Looking at matrix-docker-ansible-deploy one gets a glimpse of what extensions are already available in for a production environment.
I've a wish for the Cloudron Matrix app to be expanded with more features. This will make the app more useful and better demonstrate Matrix's versatility.
Extensions of direct interest to me:
Let's discuss what if any extensions are worthy of inclusion in the package.
@yusf I have to look into the extensions more closely but do you know if these extensions are run in-process or out of process? For maintainability, out of process would be great.
yusf last edited by
@girish I’ve no idea.
chymian 0 last edited by
infogulch last edited by
do you know if these extensions are run in-process or out of process?
Looking through the extensions it appears all of them are defined as separate docker containers, so "separate process". I think Matrix's general strategy is to allow plugging in to the server via api, instead of modifying the server itself.
I'd be interested in all the bridges, though there are a lot. If we're not careful, we'll have 20+ apps just for matrix.
Maybe we can have a single matrix integration app. I think my initial question still remains: are integrations run in-process or out of process? Does anyone have experience running these? If it's out of process, we can just bundle them all together as a separate app. If it's in-process, we have to see if these can be installable as plugins (like WP/Discourse/NodeBB plugins).
humptydumpty last edited by
This post is deleted!
humptydumpty last edited by
This post is deleted!
ericdrgn last edited by ericdrgn
@girish Does this help? I am sorry I am not as technical as some others in here but this "playbook" seems to have basically all the things. Most importantly (in my case) the bridges, with links to everything.
Maybe this would help you all see how it works and maybe provide a more "complete" Matrix instance for us to use.
ericdrgn last edited by
@girish While it seems everyone is on the same page already that all this would be great just as an addition the previously linked playbook (https://github.com/spantaleev/matrix-docker-ansible-deploy) now also includes a really nice looking moderation tool (https://github.com/spantaleev/matrix-docker-ansible-deploy) which is also sorely needed in our Matrix instances.
Still hoping we can make something happen
infogulch last edited by infogulch
There's a post about bridges from 2017 that outlines the general approaches bridges can take. The matrix-puppet-bridge project mentioned in that post now points to two other efforts Sorunome's mx-puppet-*, and tulir's mautrix-*, both of which feature in the matrix-docker-ansible project mentioned above.
It seems all Matrix plugins/bots/bridges/etc connect through the network as Application Services which (in Synapse) is configured manually by setting homeserver.yaml/registration.yaml to include authentication tokens used by the app to authorize its connection to the homeserver. This is part of what the ansible project does.
I think that ansible project is probably the best bet -- at least as a source of truth even if we don't end up using it directly, though extracting usable knowledge about correct configuration from it is not trivial. It has an faq.
I did some exploration, tracing the discord bridge's registration.yaml and noted the configuration dependency path through the playbook. I'm only mildly familiar with both ansible & matrix, but I think this helped me get a clearer picture of the configuration required to set it up; perhaps it will also help someone else:
- global secret defined
- discord appservice token is derived
- token used to build discord registration.yaml
- registration.yaml file saved to disk at a location defined here
- discord registration.yaml added to list to mount into synapse container, and added to a list to configure synapse
- the list of registration yaml files is finally expanded into homeserver.yaml to be used by synapse
- The discord bridge is configured in this config.yaml template, but it's not clear to me how it gets the appservice token to authenticate itself with the homeserver.
- The main tasks executed to install the bridge include downloading the bridge's docker image and installing a systemd service file that runs it.
The main issue I see with running the playbook on a Cloudron system is that it expects to be run as root on the base server. E.g. by default it creates docker containers, opens firewalls, sets systemd services etc. I don't think using it blind is a good idea and would almost certainly run into conflicts with Cloudron.
But lets say we could disable the problematic features, and use it to define and manage the bridge containers -- you still have the issue of getting the app service tokens into Cloudron-managed-Synapse's config.