@girish Sorry for some reason I didn't see any reply to the issue until now. Thank you so much for this! I can't wait to try it out.

Our tests use a bunch of APIs to validate updates in case it's interesting - https://git.cloudron.io/cloudron/synapse-app/-/blob/master/test/test.js#L57

@derin would be great if you could post your final working theme here when you have it working.

@hollosch this would have to be done in the upstream project. For element web this likely is https://github.com/vector-im/element-web/#translations

@murgero I don't think it does.

@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

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 !

Hi @Nexxo , have you found a solution or were able to activate the IS for Matrix?

regards

@robi That doesn't do the trick unfortunately. It results in the underlying IP of the cloudron server being exposed, which undermines the purpose of the cloudflare proxying.

So i think I still need to find a way to add in our external turn server and allow it to survive a reboot.

@senthilkumaran The CORS issue is covered here - https://forum.cloudron.io/topic/5589/cors-timeout-error-when-searching-for-public-rooms . Essentially, try giving synapse a lot of memory.

Disclosure here - https://matrix.org/blog/2021/09/13/vulnerability-disclosure-key-sharing

We pushed out update to Element already. Please update asap.

If you can get logs from the client on the remote end of the call, it will tell you what's not connecting / failing.

@cryexx I think you are in the wrong place. This forum is for Cloudron and related to the Synapse package on Cloudron. Maybe https://github.com/matrix-org/synapse is the right place for your question?

I fixed this in package 1.28.0-1

@infogulch ah thanks, i will remove it.

@nebulon
Thanks for the tip.
I will instruct my users to re-enable sync again on the Android app.

@scooke good idea, thanks

@girish said in Trying to configure element with custom background:

{
"default_server_config": {
"m.homeserver": {
"base_url": "https://matrix.cloudron.work",
"server_name": "cloudron.work"
},
"m.identity_server": {
"base_url": "https://vector.im"
}
},
"disable_custom_urls": true,
"disable_guests": true,
"disable_login_language_selector": false,
"disable_3pid_login": true,
"brand": "Riot",
"integrations_ui_url": "https://scalar.vector.im/",
"integrations_rest_url": "https://scalar.vector.im/api",
"integrations_widgets_urls": [
"https://scalar.vector.im/_matrix/integrations/v1",
"https://scalar.vector.im/api",
"https://scalar-staging.vector.im/_matrix/integrations/v1",
"https://scalar-staging.vector.im/api",
"https://scalar-staging.riot.im/scalar/api"
],
"bug_report_endpoint_url": "https://riot.im/bugreports/submit",
"defaultCountryCode": "DE",
"showLabsSettings": false,
"features": {
"feature_pinning": "labs",
"feature_custom_status": "labs",
"feature_custom_tags": "labs",
"feature_state_counters": "labs"
},
"default_federate": true,
"default_theme": "light",
"roomDirectory": {
"servers": [
"matrix.org"
]
},
"branding": {
"welcomeBackgroundUrl": "https://chat.swirlon.app/custom/background.png",
"authHeaderLogoUrl": "https://chat.swirlon.app/custom/header.png"
},
"piwik": false,
"enable_presence_by_hs_url": {
"https://matrix.org": false,
"https://matrix-client.matrix.org": false
},
"settingDefaults": {
"breadcrumbs": true
},
"jitsi": {
"preferredDomain": "jitsi.riot.im"
}
}

Oh my gosh thank you so much!!

Hi @girish, thanks for getting back to this. I have indeed figured out how to make this work.

@stantropics said in matrix / element user management:

/bin/matrix-synapse-register-user <path to homeserver.yaml> http://localhost:8008

If you are having problems setting a password I figured out it is not a good idea to manipulate the database, instead use the synapse API.

Until this point manually created users cannot login, you need to chage the config in homeserver.yaml as follows:

localdb_enabled is false by default. Change it to true and manually added users can login.

@girish said in Can't upgrade Matrix server:

If you go to Settings -> Check for updates, and then come back to matrix and try to upgrade, does it work?

Derp, that's worked. 🤦 Thanks.

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:

Also:

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.

@ericdrgn Thank you, you were right, I skipped this step.

Have you tried pressing try again? Wouldnt it be better to just create Cloudron accounts for your users? You can limit their access using groups on Cloudron level.

@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.

@martin you can open the HTML file in the file browser app or via SSH and edit it. At least for me, it appears to persist across updates.

@atrilahiji @ericdrgn I started working on this yesterday and have similar questions.

In my case I just opened 3478 TCP & UDP on inbound traffic (on a VPC in AWS) and two users on the Cloudron could then make video calls - on Nextcloud Talk and Kopano Meet.

Monitoring the STUN/TURN logs going via the Services page, I could see a few 401s thrown before connection, but I'm not sure how to read what is happenining at this stage.

Do I need to open up 5349, as well, as indicated in the post above?

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 said in Google suspended Element in Play Store:

Calls and texts are literally pushed though.

For the 10% of important people still using them. 90% of notifications to me are unnecessary, no matter how much I try to whack them with settings.

@girish Of course, makes sense now. Should be fairly easy for everyone moving forward.

@msbt hmm you are right and I was wrong! 😓 I'll test if it works and report back 🙂

EDIT: Okay it works but only for new accounts (at first login with LDAP or local accounts).
The part in my homeserver.yaml looks like this: