🧪 Testers wanted: Element Server Suite (ESS Community) for Cloudron

[andreasdueren]

@humpty yes that’s what it’s designed to do

[andreasdueren]

Pinging the Cloudron team @girish @nebulon one more time more cleanly for this, or a comparative feature request (if you give me permissions on git.cloudron.io I’m happy to commit something directly):

andreasdueren said:

Request for the Cloudron team

@girish @nebulon The apex-domain situation (limitation #1) could be solved cleanly with a small platform feature: let an app declare custom well-known entries for its parent/apex domain — either in CloudronManifest.json or via an API the app can call — so Cloudron's nginx serves e.g. https://example.com/.well-known/matrix/{server,client} and /.well-known/element/element.json on the app's behalf, without the app claiming the whole apex as an alias.

Cloudron already serves some well-known content per domain, but there's no way to set the arbitrary JSON that Matrix needs today (e.g. the org.matrix.msc4143.rtc_foci transport entry that Element Call requires), and no way for a package to register it automatically. A wellKnown section in the manifest (updated on configure/restart) would benefit any protocol using apex-domain discovery — Matrix, WebFinger/Mastodon delegation, etc. Happy to write up a concrete proposal or beta-test an implementation with this package.

[girish]

@andreasdueren is this same or different from https://docs.cloudron.io/domains#matrix-server-location ? I guess we can also add element.json there.

[andreasdueren]

@girish Almost the same, with two differences:

1. That feature only serves a fixed set of locations (matrix/server, matrix/client, host-meta, caldav/carddav). element/element.json isn't in the whitelist, so adding it to the domain config today would still 404. If you're open to adding it there, or better, serving any configured location, that solves it. I actually have a small patch for the generic version ready (branch wellknown-generic-locations on https://git.due.ren/andreas/cloudron-box, incl. regression test) if you want an MR.

2. The entries are static text the admin maintains by hand, while the correct values (e.g. rtc_foci for Element Call, the MAS auth block) come from the app and change with its config. That's the angle of my feature request: letting an app declare/update these entries for its apex domain itself, so they can't go stale. The dashboard feature would stay as the manual override.

So: same mechanism, just asking for it to be un-whitelisted and optionally app-populated.

[james]

fyi: @andreasdueren
https://git.due.ren/andreas/cloudron-box can't be accessed without an account.

[andreasdueren]

@James Oops, sorry about that. It's public now. https://git.due.ren/andreas/cloudron-box/-/commit/314e5f7a39aec36e61bc21dfced5f26dec797b96

[girish]

We can take a look at this after Cloudron 10, thanks.

[andreasdueren]

Just successfully moved my Matrix instance over to this ESS package.

[humpty]

@andreasdueren Hi Andreas. Why does v0.3.32 require a manual update?

[andreasdueren]

@humpty v0.3.32 moved the package image from Docker Hub to the new Cloudron Container Registry as part of the Cloudron 10 build-system migration. Cloudron intentionally requires manual confirmation whenever a community package changes its image repository, as a security precaution. This should be a one-time manual update; later versions from the new repository will update automatically again.