Matrix/Riot

[msbt]

@will you can just enable registration in homeserver.yaml and you're good to go

[A Former User]

well you can enable it yes, but users who registered were not able to login (?). I guess this is because it only accepts login from LDAP?

[msbt]

worked fine before when I tested it, did you also set

password_config:
  enabled: true
  localdb_enabled: true

and maybe restarted matrix?

[will]

@girish added a redirect for matrix, and it works! Is this only needed if an app lives at rimmer.cloud or do I need it regardless?

[girish]

@will Only requirement is that it should be used by some app on Cloudron. You don't need to redirect it to matrix specifically. example.com can either be any app or it can redirect to any app. (At a technical level, all this means is that the Cloudron's reverse proxy is prepared & ready to answer requests for that domain).

[will]

@girish Will this requirement be patched in a future release?

[girish]

@will there is no way around this requirement. the matrix protocol requires the apex domain to serve up those documents. is your concern that the domain example.com can be used to host a site somewhere else? If so, all you have to do is to move the .well-known setup to that server/new location.

[will]

@girish My concern is having anything at example.com
It would be cleaner to just have cloudron handle that for me. Small gripe, not a big deal at all.

[girish]

@will said in Matrix/Riot:

It would be cleaner to just have cloudron handle that for me. Small gripe, not a big deal at all.

Ah, Cloudron side limitation can definitely be fixed I agree that having to ssh and put files manually in a cryptic location is kinda crude. This will be fixed soonish but we just wanted to get the apps out for testing sooner rather than later.

[will]

@girish Dont get me wrong, Im thankful! Its great. I'm just giving a little feedback on possible improvements. Sounds like you are on it already

[yusf]

@msbt said in Matrix/Riot:

I'm guessing it is because of new keys and everything, haven't tried to re-use any of the existing ones.

Might very well be, yes. I'm going to try and migrate the keys too. The migration is hard to dry run though

[msbt]

if you want to make sure this works, you could try with a test-instance, after that a clone and then the real thing good luck either way!

[yusf]

I'm transitioning my external reverse-proxy-and-well-known solution to the Cloudron solution. Is there any way I can configure Riot to have https://domain.tld as base_url while still having the Synapse server at https://matrix.domain.tld? This way I would be able keep Riot user sessions across migration.

[girish]

@yusf That should not be a problem. Riot can be installed on the main domain as well. Just make sure the .well-known is setup on the server.

[yusf]

@girish Sorry, I meant doing so while keeping Riot at a subdomain too. I guess not?

[girish]

@yusf Yeah, I think not

[jegillikin]

FWIW, I just installed all of this and tested it. Works great, instructions are clear. The yaml edits referenced by @msbt were quite helpful on the external-registration side.

Look forward to the eventual Jitsi package.

[yusf]

@girish What if I edited the Cloudron reverse proxy settings directly?

[girish]

@yusf reverse proxy configs will get overwritten during updates. I think https://cloudron.io/documentation/apps/#well-known-uris should help setup well knowns the way you want them, no?

[yusf]

@girish Well-known is in place for Synapse already, but it seems that well-known configurations aren't enough to enable entering domain.tld as homeserver in Riot sign-in when the server is at matrix.domain.tld.

What seems to be needed is the ability to forward the whole /_matrix path at domain.tld to Synapse.

In nginx terms I belive that would look something like this:

server {
  listen         443;
  server_name    domain.tld;

 location /_matrix {
    proxy_pass https://matrix.domain.tld;
 }
}