Define custom well-known entries via CloudronManifest.json

[andreasdueren]

The apex-domain limitation for the ESS package 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.

Is this the same as https://docs.cloudron.io/domains#matrix-server-location?

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.

[andreasdueren]

@gir just putting this back on your radar since you mentioned you might look into this after Cloudron 10 was released

[girish]

Good idea, will add to the Cloudron 10.1 list to investigate @andreasdueren . We added a concept of Default apps in Cloudron 10 (which is still "experimental") . Maybe that is a fit for this too cc @nebulon

[girish]

OK, looked into this. I understand this is a generic request to auto-configure well-known via manifest. Mostly we have seen this well-known stuff practically in the mail/caldav/cardav stuff and matrix protocols. We decided it's just easiest to hardcode in the UI since so many parts are moving especially in the matrix space.

Now to address the specific matrix fields in question:

• matrix/server - this one is valid and used by matrix servers to find the home server from the address
• matrix/client - this is one is also valid and used by matrix clients to find the home server from the address. Now this is broadly speaking a "JSON document" which has m.homeserver and fields like im.vector.riot.jitsi (for jitsi) and org.matrix.msc4143.rtc_foci (for livekit). The latter fields to get the webrtc urls are obsolete and is now fetched from the home server directly (via GET /_matrix/client/v1/rtc/transports).
• /.well-known/element/element.json is also obsolete. This used to have call pages etc but since Element Web 1.11.97 and Element X 25.03.3 the call interface is bundled in the client, and Element stopped fetching this file. See also https://github.com/element-hq/element-x-ios/issues/4813

So, overall, I think we are good as-is since it seems all these fields have changed meaning already since you wrote this post. Let me know what you think.

[andreasdueren]

@girish I tested this on production with Element X on Android and iOS.

When the Matrix well-known is served by the app, calls work. When it is served by Cloudron, calls fail with Call is not supported ... MISSING_MATRIX_RTC_FOCUS. This also happens after I set matrix/client through the API so the content is identical to the app's, including org.matrix.msc4143.rtc_foci. Removing the dashboard entry makes calls work again.

The remaining difference seems to be the header. The app sends Access-Control-Allow-Origin: *, Cloudron's well-known handler does not. Element Call runs inside a webview and reads /.well-known/matrix/client with fetch(), so without the header the browser blocks the response and Element Call can't see the focus. The Matrix spec also asks for this header on the client well-known.

So the apex is still blocked for me. Two small changes should free it:

1. Add Access-Control-Allow-Origin: * to the matrix well-known responses.
2. Allow custom JSON for matrix/client. The dashboard has a single "Matrix server location" field that generates a fixed template without rtc_foci, although the API already accepts and serves custom content.