Add Element Call to cinny
Description
This PR adds Element call to cinny by using the "Matroska" approach:
- element call runs as a widget
- basic widget funtionality is added to cinny
- A simple React view is added for showing the element call widget
- the room header is altered to show a call button
If the room is switched the call will be quit/hung-up.
(This might be a blocker for this PR @maintainers?)
Greetings from the matrix conference 2025!
This contribution was present as part of a matrix conference 2025 talk. https://youtu.be/PQR-g-UjEEM?si=fEdqO9mT0y2DFRI3&t=2302
Screenshots
Fixes #
Type of change
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
- [ ] This change requires a documentation update
Checklist:
- [ ] My code follows the style guidelines of this project
- [x] I have performed a self-review of my own code
- [ ] I have commented my code, particularly in hard-to-understand areas
- [ ] I have made corresponding changes to the documentation
- [ ] My changes generate no new warnings
All contributors have signed the CLA ✍️ ✅
Posted by the CLA Assistant Lite bot.
Preview: https://2512--pr-cinny.netlify.app ⚠️ Exercise caution. Use test accounts. ⚠️
Preview: https://2512--pr-cinny.netlify.app ⚠️ Exercise caution. Use test accounts. ⚠️
Tested this instance, but had the following issue when initiating a call:
My reverse-proxy is set to forward any request under /_matrix/client/v3, and if it matters, have zero issues with calls via the Element client.
I have read the CLA Document and I hereby sign the CLA
@jackedproxy
Tested this instance, but had the following issue when initiating a call:
I think i ran into the same issue. the vite configuration to expose element call in domain/widgets/element-call/index.html seems to not work with the ci deployment (It works on localhost)
I changed the video config a little bit to see if that fixes it.
Interesting enough it works with:
domain/public/locals/en.json
Lets see if my changes fix the issue once we have the next ci build.
The ci issue you encountered are now fixed (it was not redirecting to EC correctly in the netlify build) @jackedproxy
Hi @toger5 , Thank you for this PR. We have plans to add Element call into Cinny but we want to have a consistent UI. Since you are already familiar with project, do you have plans to ship a package where devs can customize the UI?
where devs can customize the UI
This is sth we considered. Since there is so little ui it is probably very easy to expose such configuration to the embedded module. It would be a very great upstream contribution.
I still think its still the right first step to add the widget and the functionality even though the styling does not yet fit.
Is there a feature flag option in Cinny i could use to make the PR easier to merge without waiting for the EC styling work?
This is sth we considered. Since there is so little ui it is probably very easy to expose such configuration to the embedded module. It would be a very great upstream contribution.
Actually I would like to contribute more in direction where the element-call functionality can be made available as an sdk independent of UI and underline matrix-js-sdk. It will really help to shape features more freely and independently.
Actually I would like to contribute more in direction where the element-call functionality can be made available as an sdk independent of UI and underline matrix-js-sdk. It will really help to shape features more freely and independently.
Element call is already starting to adopt a mvvm pattern. So it probably is possible to use it as an sdk to some extend where one only builds the views.
On top the js-sdk matrixRTC bits are also build so they are easy to pull out into an external SDK (using interfaces instead of relying on the exact room, client objects exposed by the js-sdk)
@ajbura I think actually building and maintinging a second version of element call with a custom view is still a larger project than this PR + some styling configuration for element call.
Is there such a thing as a feature flag which would allow adding the EC version already as a stop gap while waiting for the other more ambitios plans?
An iteration could be:
- add theme configurations (corner radius tiles, corner radius buttons, icons buttons, highlight style tile speaking, highlight style tile riase hand ...) to EC and use non default values for them in cinny.
- publish a cinny call embedded package that is a project which uses element-call as a dependency (best case not a fork but using EC view models as a npm module)
- build a proper call sdk + matrix rtc sdk and use them to build a fully custom call solution for cinny.
Is there such a thing as a feature flag which would allow adding the EC version already as a stop gap while waiting for the other more ambitious plans?
Currently we do not have any feature flag thing and are not planing to introduce. Our main goal for any new features is to make it usable enough so users do not have to go through disruptive changes, we also do not collection any "usage statistics" so adding test features wont really work without filling inboxes with rage comments.
This PR is a good proof of concept. We need to go through the planning various things before adding embedded version. Like:
- designing call experience as currently it covers the chat-area, drastically reducing its usability.
- making call rooms responsive to various screen size.
- making sure call doesn't end when switching rooms.
- making embed responsive to theme change.
- deciding does call feature will be available in public rooms(where it might not be useful). Does calling is a DM thing, Does is it a video room thing, Or a standard feature for all rooms?
Unfortunately this doesn't seem to be working any more. I get MISSING_MATRIX_RTC_FOCUS when attempting to start a call. Does it not look at the value of ./well-known/matrix/client?