You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All dependency services for Element Call (LiveKit Server and LiveKit JWT Service) can run under a subpath (e.g. matrix.example.com/livekit-server and matrix.example.com/livekit-jwt-service), so I'm favoring a default configuration which runs these services there. This allows people to easily get started without having to create additional DNS records.
It's just Element Call that requires a dedicated domain and DNS record, which makes it harder to setup.
As far as I see, none of these services are really "user facing". Most people would be accessing Element Call via a widget spawned by their client. Most users would not even know (nor care) which URL Element Call is loaded from.
If Element Call could also run under a sub-path on an existing domain, setting up the whole Element Call stack could happen without any extra DNS setup work.
How would you like to achieve it?
I'd like to pass some additional config.json setting or environment variable to indicate to Element Call the path-prefix it should use when generating its own URLs.
What is the current state of things?
Setting up a reverse-proxy to strip the prefix (e.g. /call) and forward the plain URLs (/call/config.json -> /config.json) to Element Call works.
What doesn't work is the fact that Element Call generates these URLs without being aware of a path-prefix, so all URLs are plain (e.g. /config.json being hardcoded in index.html as seen here, etc.).
Now, hosting Element Call on the Element Web (or other existing) subdomain may have security or other implications, so these should be considered as well when making this decision.
Have you considered any alternatives?
I don't see any alternatives that let users avoid the need for creating additional DNS records.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Any clues as to what the timeline for that would be? On the order of days, weeks?
I'm just wondering if it's worth waiting for it or if we should just launch without it and plan for adding sub-path support later (while not breaking the config for existing users).
Your use case
What would you like to do?
I'd like to host Element Call under a path-prefix like
/call
on an existing domain (e.g.element.example.com
).Why would you like to do it?
I'm wrapping up Element Call support in matrix-docker-ansible-deploy (initial work happening in this PR).
All dependency services for Element Call (LiveKit Server and LiveKit JWT Service) can run under a subpath (e.g.
matrix.example.com/livekit-server
andmatrix.example.com/livekit-jwt-service
), so I'm favoring a default configuration which runs these services there. This allows people to easily get started without having to create additional DNS records.It's just Element Call that requires a dedicated domain and DNS record, which makes it harder to setup.
As far as I see, none of these services are really "user facing". Most people would be accessing Element Call via a widget spawned by their client. Most users would not even know (nor care) which URL Element Call is loaded from.
If Element Call could also run under a sub-path on an existing domain, setting up the whole Element Call stack could happen without any extra DNS setup work.
How would you like to achieve it?
I'd like to pass some additional
config.json
setting or environment variable to indicate to Element Call the path-prefix it should use when generating its own URLs.What is the current state of things?
Setting up a reverse-proxy to strip the prefix (e.g.
/call
) and forward the plain URLs (/call/config.json
->/config.json
) to Element Call works.What doesn't work is the fact that Element Call generates these URLs without being aware of a path-prefix, so all URLs are plain (e.g.
/config.json
being hardcoded inindex.html
as seen here, etc.).Now, hosting Element Call on the Element Web (or other existing) subdomain may have security or other implications, so these should be considered as well when making this decision.
Have you considered any alternatives?
I don't see any alternatives that let users avoid the need for creating additional DNS records.
Additional context
No response
The text was updated successfully, but these errors were encountered: