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)
@yusf Are backups failing by any chance. I wonder why there are multiple backups in a day. How often do you create backups? If it's one week backups from 17th Npv are expected. the ones which are slightly older are probably preserved for various reasons. One thing you can do is Backups -> Cleanup backup. Then in the same view, click on logs and it will tell you why each and every backup is preserved. If you paste the log, I can explain in a bit more detail.
@fbartels "Basic auth" is only what happens between the browser and the server. The server can verify a request that uses basic auth against any authentication back-end, including an LDAP server. I actually did something similar for the Transmission in my River app: as Transmission also uses basic-auth, the various mobile-apps & browser extension need it to work, so I had to accept it for them to work. This UI makes me wanna try to package a docker registry for cloudron... I'll have to dig deeper into how it works 🙂
@girish In my case I was trying to mirror the content of a remote DO object storage to a local Minio instance. I can't recall the exact error but I remember it had to do with the handling of filenames.
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.
Sorry, I didn’t intend to bash on WeKan. Wrote that in a rush. I use it too and it’s great. ”Lifesupported” doesn’t really describe the state of it. What I really think is that it feels something like ”actively maintained” and not releasing new major features (at least not for as long I’ve used it).
Thus I found Citadel’s roadmap interesting, seemingly with a focus on Trello feature parity and parity with some popular 3rd party Trello extensions.
Until that’s actually a thing though, I’m sticking with WeKan, of course.