Expand Matrix app features
-
@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.
-
E ericdrgn referenced this topic on
-
E ericdrgn referenced this topic on
-
@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.
-
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
-
@andreasdueren @girish Has there been any progress in getting addons to work?
This list of Docker containers seems comprehensive, if a little overwhelming: https://github.com/spantaleev/matrix-docker-ansible-deploy/blob/master/docs/container-images.md
-
@jdaviescoates This does look good!
@girish any chance of converting this to a Cloudron install?
-
@girish Yes, Slack integration is my immediate need. I believe 'puppeting' is the best way, although I don't know much about it.
A RSS > #Channel would be nice to have too.
As an aside I think https://github.com/42wim/matterbridge#readme exists as a Nextcloud module, but I'm not sure if that helps here? https://github.com/nextcloud/talk_matterbridge
-
-
E ericdrgn referenced this topic on
-
@girish said in Expand Matrix app features:
@Sam_uk are you looking for a specific connector? I think adding all of them is not going to be "sustainable". It's just going to break with all releases and dependencies.
For me it's really only the WhatsApp bridge. It's by far the most popular chat service, requires no API access with a complex registration process or high fees and is fairly easy to use. I am basically currently running a separate server with yunohost just so I can use the bridge and would love to change that.
