Yes, I ran & still run a Jitsi instance and a website which would connect you to one of 12 participating Jitsi server at random applying to our guidelines in the EU.
My goal was offering a low-barrier open for all way to connect with loved ones. During the peak of the Covid pandemic for many people it was easier to connect with colleagues than family members or friends. So I contacted a few sysadmins and public organizations of whom I knew were running Jitsi and asked if it could be shared via our public website. A few agreed and a few dropped by and wanted to help out. After a few days a commercial hosting company decided to sponsor us with one VPS as well.
Our idea was to connect the servers and use the API to select a server with the lowest load. In the meantime we used a randomizer...we've never used the API after all, the randomizer worked well enough ;)
People told us they've used our free service for yoga classes, library book reading clubs, hackerspaces & celebrating birthdays with grandma.
Overall I'm still very proud what we've achieved in a few days with some servers, opensource software and bit of work.
Many thanks to @saghul, 8x8 and all other people contributing to Jitsi. Thank you!
I run a Jitsi instance on Linode. I used their push-button setup, then tweaked the security settings slightly. I keep it off and on a minimal instance except when it's time for a meeting, at which point I move it to a dedicated host for the duration of the meeting. I always check my TLS/SSL certificates and update the OS before the meeting, too. It has been okay, but not as reliable as Google Meet or Zoom. There's often someone having audio issues, typically on an iPad. Before I switched to a dedicated instance, those problems were worse. One of my regular meeting participants co-founded the FSF, so I'm using Jitsi so that we're using open-source software. I'm a big fan of Jitsi, but I want to be realistic about its reliability in my experience.
It's hard to tell. There are typically only three or four people in the room at most, and the iPad audio problems typically occur with even fewer people.
I believe that the iPad user is using the web, not the app.
Wasn't there news recently about Safari overtaking edge as the second most popular browser?
If so, we should probably be developing for it too. Not just the top 1. Yes, there's a gap between 1 and 2, but you can't just discount it when building an app.
I'm looking forward to Element Call, which is currently in development.
It looks like their design starts with WebRTC running through SFU (selective forwarding units), which is pretty common by itself, but they're adding a tree-like SFU hierarchy in order to handle many participants without requiring expensive MCU (multipoint control unit) servers.
I assume it will become part of the Matrix spec rather than being an Element-only feature, though I don't think I've seen that confirmed. Maybe Arathorn will see this and comment?
Contrast with Jitsi, which requires Java, making it too heavy for my low power ARM server, and does end-to-end encryption in a way that's too heavy for some of my contacts' web browsers to run smoothly.
In the meantime, I've been relying on my Mumble server when I don't need video. The sound quality and latency are top notch, and the hardware requirements are low.
The thing keeping it in beta has been a set of really annoying intermittent bugs, which we’ve ended up tracking down by adding full opentelementry support; should expect to exit beta in the next few weeks (currently gathering data to check we really did fix them). Meanwhile we’re experimenting with other SFU implementations (eg LiveKit) to see if we can avoid reinventing the wheel there.
Element Call style VoIP is already proposed for the Matrix spec - MSC3401 and MSC3898.
Hey, I'm part of a team that self hosts a jitsi instance. I've made a small plugin that uses some CSS-hacks to make the buttons in the bottom of the call also have text, and not just icons. It makes it much easier to explain to someone which button you need to press to access the chat, or begin to screen share.
Instead of sharing the ugly CSS-hacks here's just the list of what I've named the buttons, the CSS-hack isn't something I would expect to make it upstream so to say.
From left to right:
- Mic
- Webcam
- Screen share
- Chat
- Hey! (it's willingly ambiguous so that someone might stumble upon the feature in a exploratory manner, we don't really use the "raise hand" function in a serious way)
- This call
- Layout
- More actions
- Leave
A serious pain point is that Jitsi stopped supporting Ubuntu 18.04 with no warning, well before its EoL date.
An update led to a dependency issue (I would have to go remind myself which but I think Prosody) and that was that - just a ‘well lets stop supporting Ubuntu 18.04 then’.
I think over time the advice has been to go manually downgrade some packages or try and find the relevant versions somewhere. A more satisfactory solution would be to support the up to date versions of dependencies available to the distribution jitsi is installed on.
We’re getting to the point where this doesn’t matter of course, as 18.04 goes end of life. But you can understand why we are reluctant to recommend jitsi as a stable and reliably maintained option after this experience.
I attempted self hosting it on an RPI4 but the video quality was dropping heavily and stopping alltogether from time to time. I did not see an obvious bottleneck anywhere in the system. The rpi had both ram and cpu to spare, my connection is 1gbps down, 100mbps up. Should be more than enough for two people.
This was early this year. I followed the official guide word-to-word. Others reported similar issues on the official forum so my issue isnt new or unique.
I've set one up before when the pandemic was in full swing. I haven't really been stuck in group call hell for well over a year with my work now but at the time I was really impressed about how much higher the video and audio quality was over what zoom had at the time.
The only complaint we had was the mobile performance. Made older phones hot and killed the battery fast.
Public documentation on how to automatically install + configure the Debian packages would be great (i.e. using debconf-set-selections). I've figured it out from forum posts, etc. in the past, but it keeps changing, causing my installation scripts to get stuck waiting for user input.
I seem to always have trouble with video freezing or very low quality audio+video. Jitsi just isn't reliable enough for me. We've switched to BigBlueButton on the same type of server and it runs gloriously, with HD video, crisp audio. I kept giving Jitsi a chance, but it disappointed us too many times
Just wanted to say thanks as well. I host a private Jitsi server for my online teaching. It took a bit of effort to set up but worked well for me since.
Since December I've been running a jitsi instance just for family and friends. It's been working well for me, and I like that I can just send a link to anyone and they can click it and join the call in a browser without messing around.
Edit: since this in HN, I'll mention too that I don't even bother with passwords. I set up basic auth on the endpoint for management and room creation, and just leave the room(s) open. For a low key chat-with-friends-and-family setup, it's great and I haven't had to touch it since I set it up.
It's about $40/month, but it's my personal server for everything else too. Hosts some web radio projects with liquidsoap and icecast, some generative audio experiments, and so on. It's still probably more server than I need.
Edit: remembered that wrong. It's $66/month. But I'm using an instance much larger than you'd need to just run jitsi.
You can get so much mileage from a $40 hetzner instance. Mine is doing all forms of useful things. My only critique is that latency to storage boxes is awful (and storage is otherwise really pricey).
I run a matrix server deployed using their annsible script [1] which comes with jitsi, etherpad, etc.
The setup was a bit of a hassle (need to get the domain configured for federation, updating the config files etc) but after a weekend of configuration it has been rock solid since (in operation for a year now). I use it primarily as a centralized chat client (using bridges to the various propriatary chat services) but it is nice to be able to throw up a quick jitsi call and/or etherpad document.
The whole ansible/docker stuff is over my head, but these days I just run the playbook to apply updates and it hasn't failed me yet. Backups are handled by taking snapshots of the VM it runs in.
The jitsi web client works great on desktop, but I would recomend using the dedicated mobile apps because I have heard reports the web client struggling on mobile.
I'm running Jitsi in Docker on a VPS. I use it for voice + video chat while playing online games with friends. For this use case, I had to do almost no tweaking from defaults, so I have not become a Jitsi expert at all. It's been running for about a year with no issues I can remember.
One annoyance was that I couldn't figure out how to set up a persistent room protected by a code. My goal was to have no usernames or passwords, but without allowing completely open access - I just wanted to distribute a room name and single known password/passcode my friends could use to get into the room.
Since this didn't seem to be possible at the time, I settled for requiring rooms to have a "host," which is just me. That way I deal with a username and password, but nobody else has to. It does make it impossible for the rest of the group to play without me, but this isn't an issue for our situation.
Unfortunately I don't have a very helpful answer - it's free to me. I said VPS as a simplification, but the actual situation is some co-colocated hardware a friend of mine runs. He gives me a virtual slice of it because he has excess capacity.
That said, compute-wise I would expect Jitsi to run fine on a $5 droplet or similar. Probably have to watch out for bandwidth costs, I haven't been monitoring my usage because I don't have to.
I set one up on my basement server when the pandemic hit for my church, since Zoom's free meetings were limited to 45 minutes. I was able to allow Jitsi to run as a web app on phones, but people complained that it ate through their batteries fast and caused them to get hot. They went back to meeting in person outdoors, and didn't need it. I turned it off after about a month, and haven't needed to look into it again.
IRC + Jitsi could work for a lot of people, but there's still enough trust in big centralized platforms for people to be satisfied with them.
It's not clear that regular people care about where software is hosted. If anything it's just far more convenient that you don't have to deal with anything. Did anyone care how secure zoom was? Not really. Just pure convenience.
I've been hosting it for about 2 years, running in a container on a Proxmox host (a DL380G7 with 128GB RAM and a DS4243 JBOD in a tailor-made enclosure under the stairs here at the farm) together with a bunch of other services. It is not used all that often but when I need it it is there and works as intended. After configuring it I have not had to do anything else than run apt update && apt dist-upgrade every now and then. It is a bit of a memory hog just like most other jvm-based services but it is reliable and dependable.
Do you have a handle on how much of a memory hog? I've considered installing it for a small group of people (~15 total, likely no more than 6 actively on a video call at any given time) but the dedicated server I'd put it on only has 32Gb in total (though it does run very little else that needs much memory: a large filesystem for backups, a web server hosting simple stuff, a LanguageTool self-install, occasionally other things I'm tinkering with that benefit from more bandwidth that the ~12mbit I currently get upstream hosting things at home).
We did it for a long time but finally got pushed into Zoom due to edge case issues like distorted audio for some participants and the need to support really big meetings. We pretty much have to buy a Zoom subscription due to sales calls anyway, so we had it.
In my experience Jitsi actually works better than Google Meet and I like self-hosting it, but Zoom works better than any and all WebRTC-based solutions.
The hard thing for things like Jitsi is that they have to work in the browser and are therefore held prisoner by how good the browser is. Most of the issues we ran into are probably browser issues not Jitsi issues since we also have tons of problems with Google Meet.
Well, I for one host my own Jitsi instance because of Internet censorship. The censorship is very bad here so major social media like WhatsApp and Telegram etc are blocked. And for cases such as Skype and Google Meet which aren't blocked the connection is sometimes throttled (not to mention that sometimes they just cut the Internet off) so that leaves one option: a self-hosted Jitsi instance on an Iranian data center.
Fun fact: Even on an Iranian data center, I had to limit the video quality on my own server to 360p because other qualities don't work great either.
Authentication can be another important one, if you want to integrate with your existing SSO or other auth mechanism.
Last, customization. While this can be done via JaaS too (our CPaaS offering) you will always have full control over your deployment if you self-host it.
For my use case, I also use the hosted version. It's worked great, and as Zoom tightens the belt on meeting duration I am shifting more of my meetings to Jitsi. No one has ever complained, and I've asked folks for feedback to see how it compares to Zoom/Google. IME it's about the same as Zoom, and better than Google or Teams.
Yep, I ran one on bare-metal for many years, then a Jitsi-Meet server as a 'replacement' while running the original for 1-on-1 calls so the execs could use the full end-to-end crypto.
Jitsi is great, IMO. Highly recommend.
I've left the company since, I believe they were bought out and switched to MS Teams now.
Yes, in a commercial setting. It's somewhat complicated as a stack, but when everything plays together, it's low latency, good quality, flexible and scalable across regions.
Only downside in my experience: cross device video never works?
Good luck making a video call with chrome + firefox + android clients in the same room.
> Jitsi is a set of open-source projects that allows you to easily build and deploy secure video conferencing solutions. At the heart of Jitsi are Jitsi Videobridge and Jitsi Meet, which let you have conferences on the internet, while other projects in the community enable other features such as audio, dial-in, recording, and simulcasting.
Is it like self-hosted Zoom alternative? I feel like if an org is on Teams, they'll just use Teams video conference. Same for Slack. I used to work at an org that had Teams + Slack + Google Hangouts/Google Meet + Zoom.
Yes, I had hosted it on Digital ocean for a long time to bypass telco regimes where FaceTime and WhatsApp is blocked for A/V calls.
It worked pretty well. I was scared of security issues where I thought some miscreants might have calls and I get blamed for it. There were security issues(which probably could be fixed but I didn’t spend too much time)
I was, but haven't for a year or so. It was handy during the COVID lockdown when I lived about 100 miles (three or so hours drive) from my mum and she wanted to see her grandson.
Really the only reason I took it down was I moved my hosting to another server and never bothered to set it up.
No but my networking group does, which I thought was an interesting choice. It was because the whole 'zoom is insecure' thing was going around when the pandemic hit. It's worked out OK ish, they're still using it after 3+ years.
Using the Jitsi website has worked well enough for me for years, and the calls are P2P as far as I'm aware. What's the advantage of hosting your own? Just preventing jitsi.org from seeing call metadata?
I wonder if you could get more reliable performance by planning a more centralized location. My book club uses the main jitsi site and it works well all things considered, but it's not perfect by any means. We've got people in several US and EU time zones showing up with varying internet connection qualities, so it's a difficult case.
But hey, it's free. And it hits the most important consideration: it could not be easier to use. That's pretty critical since my club mates don't have much capacity for troubleshooting.
Zoom costs money beyond 40 mins, unlike Jitsi. It also doesn't require anyone to have an account, or to install any software. These are key differentiators in my book!
Jitsi is footing the bill if you use the hosted product. If you don't want it to shut down or become expensive, you need to take a look at how the server is being run.
With self-hosted, you're simply paying for the servers. If you can pay for the servers and maintain them, you can be confident they'll stay up.
The hosted product is great, it just seems separate and off topic to me.
I host Mumble/Murmur for multiuser VoIP as it’s super lightweight and the noise cancelling + mute options are convenient. For 1-on-1 calls, I just use XMPP (Prosody) with TURN (coturn) and it’s handled video just fine. I’ve not had a reason to introduce anything heavier.
I did have a Jitsi instance, but when Nextcloud Talk fully developed, I shut down the Jitsi instance. The Nextcloud suite has so many features that makes it a winner for me. Nextcloud conversations can only be started by someone with an account, but I could publish guest user credentials if I want to make it public. On my personal contacts web page, I have a link to a conversation that allows anybody to call me through the web browser. My phone rings and we have a private conversation.
I've been running a Jitsi server for a few years on my home network. Came in very handy during the lockdown. The setup is Jitsi running on a Debian 11 VM that is on a CentOS Stream 8 host. The hardware is an Intel NUC which has 16G of RAM. The VM has been allocated 4G. The typical number of users in one session is about 15. This Jitsi server is reachable via the public Internet as well as on my own Wireguard network.
Since the start of the pandemic I've been self-hosting a Jitsi instance on Linode for my hypnotherapy business -- partly to transmit high-bitrate audio, partly for privacy and partly for compatibility, since it works in most web browsers. It works well even internationally (over a broadband connection), to the point where I won't even consider commercial software for this use case.
What is the best open source video chat web client?
I would love something with visible feedback on connection quality, especially if it was able to reduce bandwidth usage as possible automagically (switch video to static image / off, reduce audio kbps, etc.) to degrade gracefully.
Maybe supporting "push to be the only mic unmuted" could lessen the bandwidth needed.
If you're talking about Jitsi Meet, and to add another perspective: I have tried to install it and failed. Specifically, you could see that other participants have joined, but you could not see their video.
I have tried to set it up in different ways multiple times, following all the steps of the fantastic documentation meticulously, with full server resets in-between, researched the error messages thoroughly and even asked in the Jitsi forums, but there was just no way.
But if it works, it's a great piece of software that's easy to set up with really great documentation. I'm blaming the fact that it didn't work out on the hosting company (Strato) and their wonky VPS.
I've been hosting one on a bare metal Ubuntu server on a 1GB connection since the summer of 2020. It's been very robust and just keeps getting better with every update. I think the most users in a room was about 20.
I use the hosted version and tried it out after seeing it on HN a couple years ago. I have slowly increased my percentage use over the years, and now that Zoom is limiting 1-to-1 calls to 40 mins (used to be unlimited), I am moving over to Jitsi.
Everyone I've talked with says it's easy to use, and connectivity has been just about as good as Zoom.
We run one at mayfirst.coop. works great. We have our own plugin to support bilingual meetings and we reduce the video quality intentionally to reduce server usage and carbon impact.
No, but I use 8x8, which is reasonably priced. I don't see the point of hosting yourself when that is so good, unless it is for privacy / sovereignty sorts of reasons.
Was running it for company but for some reason the code quality on share wasn't good (not sure if due to our installation). Switched to BBB (Big Blue Button) which has more options. I can highly recommend both.
De facto School Management platform in Latvia uses self hosted jitsi for remote classes. They can all be scheduled there and meetings organized within jitsi. Got implemented when pandemic hit.
We had a self hosted Jitsi for a while but disliked it - stuff went broken too often on upgrades. Switched to BigBlueButton now which works better for us.
Setting is up is easy but the user experience is really bad :-( I'm on Google fiber and Google Meet works great and even MS Teams works fine. But whenever I use Jitsi either A) the call participants keep getting disabled/enabled or B) when video does come through my computer crumbles to its knees. Oh, and by the way, good luck using anything other than Google Chrome!
At least for me the problems start when 15+ people join the call (about the size of a small classroom). I've tried both their hosted platform and self-hosting ¯\_(ツ)_/¯
My goal was offering a low-barrier open for all way to connect with loved ones. During the peak of the Covid pandemic for many people it was easier to connect with colleagues than family members or friends. So I contacted a few sysadmins and public organizations of whom I knew were running Jitsi and asked if it could be shared via our public website. A few agreed and a few dropped by and wanted to help out. After a few days a commercial hosting company decided to sponsor us with one VPS as well.
Our idea was to connect the servers and use the API to select a server with the lowest load. In the meantime we used a randomizer...we've never used the API after all, the randomizer worked well enough ;)
People told us they've used our free service for yoga classes, library book reading clubs, hackerspaces & celebrating birthdays with grandma.
Overall I'm still very proud what we've achieved in a few days with some servers, opensource software and bit of work.
Many thanks to @saghul, 8x8 and all other people contributing to Jitsi. Thank you!