@scooke : thank you
Yes, I have another app on the domain.
I pressed 'save' to re-save and re-start it.
The domain.tld/.well-known/matrix/server returns a response.
But the tester link you gave returns an error
Get "https://22.214.171.124:8448/_matrix/key/v2/server": context deadline exceeded (Client.Timeout exceeded while awaiting headers)
And complains there is no SRV record.
Seems to me that the tester is not compatible with Cloudron matrix installs which are on :443
Maybe it's a DNS propagation issue as it's been changed ... but has it really? because Cloudron installs are under a wildcard in my case.
I will try again in a while in case it is a propagation issue.
But there is one change.
Previously Element said "cannot find" your server incroyable.net, and now it says "you are not allowed to view this server's rooms list" and I could successfully join your room with a direct link.
And I can find some other random servers also.
Think I can this is now working, despite tester link errors.
Many thanks for your help !
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:
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.
@atrilahiji so the apps can be installed on any domain really but for the user/channel handles to work in federation, the base domain (in your example domain.com) needs to provide information where to find the backend servers. That information is stored in a well known location.
We've just added those cases in the domain configuration directly, to avoid users having to edit text files in specific URL paths, which can be error prone.
Yes, they’re all separate servers. But they each need their own port into the synapse server.
My suggestion is to leave some extra ports open instead of trying to assemble an app with all/most/some of the appservices.
This way we can integrate appservices today rather than dreaming about 20 maintained ones sometime in the future, if ever. (Wouldn’t blame anyone for not trying to maintain 20 wildly different appservices since they’re all very fluid pieces of software)