Expand Matrix app features
-
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:
- synapse-admin
- synapse-simple-antispam
- email2matrix
- mautrix-facebook
- mautrix-telegram
- mautrix-whatsapp
- mx-puppet-instagram
- matrix-appservice-irc
- matrix-appservice-discord
- matrix-appservice-slack
- matrix-appservice-webhooks
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.
-
@girish I’ve no idea.
-
@girish said in Expand Matrix app features:
@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.
what's the status of expanding matrix with bridges?
is there a how-to? -
@girish said:
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).
-
This post is deleted! -
@humptydumpty not sure if this will solve our problems (I'm also not sure how Matrix works behind the scenes or the integrations), but we do have a request already in the App Wishlist.
-
This post is deleted! -
@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.
-
@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
-
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
Also:
- 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.
-
Referenced by
ericdrgn -
Referenced by ericdrgn
-
@girish said in Expand Matrix app features:
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).
@girish Your question is a year old but is something I've been thinking about of late, so thought I'd weigh in here on a couple of thoughts:
-
There is an open source alternative integration manager to the one that the matrix folks put out there: https://dimension.t2bot.io/. It adds some useful things from a cloudron perspective: the ability to more "natively" integrate a cloudron etherpad, inc. with authentication (vs the public one) and to integrate things like the Cloudron Jitsi as a widget. This would provide a nice way to tie together a variety of Cloudron apps into the Matrix/Element whole. It sits separately and would be a separate app.
-
Having said that, to my mind the biggest things to add would be bridges to Signal and WhatsApp. I have previously set up the Signal bridge (on my laptop and, as a result, only available to a local CLI client) and really liked it. Since then, I've taken out a personal Element One account to experience these two bridges further and really love it. I think it is the killer feature (and a reason why they charge so much for it!). So if it were me, I would focus less on the widget integrations and on these two additional bridges, plus telegram. From what I can tell, they can be run from unconnected to the container running synapse (as I did with Signal) or directly connected to it, which seems to make things easier to set up from the instructions on matrix.org (see the WhatsApp instructions: "If synapse is running outside of docker, you'll need to expose the port. Note that in most cases you should either run everything inside docker or everything outside docker, rather than mixing docker things with non-docker things."; Signal instructions are here; Telegram here). Both would be awesome and, I suspect, would be a real driver of people towards Cloudron generally. But to my mind, I would have WhatsApp, Signal and Telegram bridges built in as default with Cloudron if only because it would be incredible for marketing purposes for you.
Edit: additional language from instructions i wanted to highlight: "When you put the bridge and Synapse in the same docker-compose file, networking should work out of the box, which means you don't need any of the commented ports or networks things in the example compose file."
-
-
I wonder if this topic is still being followed. I agree with @eganonoa that having this set up in our cloudron instances may be of interest of many instead of Element One.
I'm a happy Element/matrix user at work and I think it would be a killing app to be able to expand that further.
-
@chetbaker This topic is definitely followed by me.
As i am also an real enthusiastic user of Elements/Matrix. I agree that this is a must to have on Cloudron-Elements... -
Hi, it would be fantastic to have the integration included in Cloudroun
-
If anyone is running the irc bridge, there is a security issue - https://matrix.org/blog/2022/05/04/0-34-0-security-release-for-matrix-appservice-irc-high-severity
-
I noticed this recently over on beeper.com
Can I self host?
We decided to open source all our bridges to enable you to audit how Beeper connects to each chat network and verify the security of your data. The side effect is that you may self host if you prefer.
There are two options for self hosting Beeper:
On-premises, managed by Beeper: run our install script on your amd64 server or 4gb Raspberry Pi and run all bridges locally on your own hardware. This option requires a Beeper subscription.
Self-host the full stack: The simplest and free way to self-host the full Matrix+bridges stack is with this Ansible script -
Has anyone tried yet if the docker container works out of the box for the signal bridge? https://docs.mau.fi/bridges/python/signal/docker-setup.html
