Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hosting under a sub-path #3084

Open
spantaleev opened this issue Mar 12, 2025 · 2 comments
Open

Hosting under a sub-path #3084

spantaleev opened this issue Mar 12, 2025 · 2 comments
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements

Comments

@spantaleev
Copy link
Contributor

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

@spantaleev spantaleev added the T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements label Mar 12, 2025
@hughns
Copy link
Member

hughns commented Mar 12, 2025

You might get what you need as part of #2994.

@spantaleev
Copy link
Contributor Author

Sounds good!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-Enhancement New features, changes in functionality, performance boosts, user-facing improvements
Projects
None yet
Development

No branches or pull requests

2 participants