This Issue tracker is only for reporting bugs and tracking code related issues.
Before posting, please make sure you check community.jitsi.org to see if the same or similar bugs have already been discussed.
General questions, installation help, and feature requests can also be posted to community.jitsi.org.
When you put in for example meet.google.com/roomname, you connect to roomname on the default jitsi server.
https:// which then connects correctly./ i.e. in this case the meet.google.com server.You mean the default server preference inside the setting is not enough/intuitive?
@luixxiul Not exactly...
So when you open the app at the top there is a bar with the tag meeting in it.
What I would like is for it to be slightly more intuitive to go to a custom server.
That is by automatically adding the https:// when required.
The current behavior is an odd hybrid approach.
Connecting to meet.google.com/roomname connects to roomname on the default server, while I would have expected it to either connect to a room called meet.google.com/roomname on the default server, or roomname on meet.google.com.
This could be just that my mental model doesn't quite align with the core devs.
Just as an FYI I love the service currently, the link connecting is fantastically simple (my granny has managed it at this point :) ), just inside the app it can be slightly odd to connect to a given URL.
This is indeed a bug. We should be able to infer the URL scheme even if omitted.
Yes, this needs to be fixed, as we have users who are lazy and do not prepend https:// and then wonder that users end up in two separate rooms: on our server and on meet.jit.si.
Determining the foreign sever whether we have a slash in the name is however a contradiction to allow slahes in room names #6597. We really need to check if a jitsi server responds.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Bump to check the progress of this? It should be a relatively quick fix, but unfortunately for this and other reasons (mainly aws killing my server) I've personally had to move to other products for videoconferencing.
Most helpful comment
This is indeed a bug. We should be able to infer the URL scheme even if omitted.