@nebulon Yeah, but like @girish said it isn't like it ever really hits that. And if I remember right I think I found that out via some Matrix bug and their blog posts. I think the situation has improved recently but don't think it is a Cloudron issue.
Anyway I self host so upping it to that wasn't a problem for me. Since it never mantains usage at that level I wasn't too worried about giving it that much I just got tired of random rooms still needing even more due to spikes so I just gave it a relatively absurd amount. On other instances where I have federation disabled I keep the default and have no issues.
@scooke I just checked the domain, and assuming it isn't a decoy one, nothing loads. So, you need to install an app on that domain!
This site can’t be reachedleanrtosolveit.com’s server IP address could not be found.
Checking the connection
Checking the proxy, firewall, and DNS configuration
Running Windows Network Diagnostics
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)