I’m loving jitsi, I’ve built a prototype video party app this week focussed on lockdown parties and fixing the things that don’t work for big parties over video chat. We’ve had a couple of parties on it and boy has it performed admirably.
However, there’s a big “but”. The documentation is abysmal. I’m sorry but that’s the cold hard truth. It’s been a nightmare to understand the pieces working while also using their libraries. Incredibly hard to read, and incomplete, docs. I’ve had to refer to the source to try figure things out most of the time. I say this because I think there’s soooo much potential there if it was more accessible. If you’re from jitsi and are keen for some good and critical feedback then hit me up, I’d love to help you out.
Though Jitsi is also usable via "zero-install browser only", the electron package allows additional features like e.g., desktop sharing with remote control.
And due to bundled Chrome, some Firefox RTP problems are also circumvented with the Electron desktop version.
You cant run browser extensions in your electron app, but you can in the website version. So for privacy, expect more tracking, fingerprinting and less control. That's not the case for Jitsi, just in general all electron based website wrappers.
I haven’t tried this, but I have been on Zoom meetings with 30 simultaneous screens going at a good framerate on a normal device in Gallery Mode, and 400 participants.
That seems to be Zoom’s signature achievement. I have not had any other commercial app even come close.
we’ve used it with 30 users in gallery mode, works fine. Another group has used it with 500 people, and it seems to have worked as well.
A major issue is still Firefox, as Firefox does not support simultaneously sending two WebRTC streams, so Firefox users heavily reduce performance for all other users as well, but the rest seems to work just fine.
Is there an issue on Firefox side tracking this problem ? as it seems a very big problem for that specific use case, and may be one of the reason why slack / teams etc. don't support firefox in their webapp ?
It would be great if it could work. I am a bit of an Electron skeptic, though. Maybe browser canvases can give decent native performance, and we could dispense with Electron.
I agree about Zoom’s failings. The existence of Facebook is living proof that privacy is a concern for only a relatively small number of folks.
We have tried Jitsi a few weeks ago. And we couldn’t scale to meetings with more than 5 people. We tried our own server and theirs.
Then there is Skype and Hangouts. With both I can only meet for two hours or so on battery.
Somehow Zoom works flawlessly. Very easy setup and it worked straight out of the box and is not CPU hungry.
The UX is also great. It’s clear what the buttons are and do. Compare that to Skype where it’s not even clear when something is a button, and even then it’s often just an icon, which means nothing to me.
The product is great. But you pay with your personal data, I guess...
> The product is great. But you pay with your personal data, I guess...
I doubt it's any worse than what you give out to Google or Microsoft for their solutions. After all, those are targeted advertising companies. Zoom had bundled the Facebook SDK to enable their social login, but removed it after the discovery that it phones home.
Lots of people up in arms about Zoom et al but I personally don't care. If Microsoft or Zoom wants to foot the bill to give me HQ video I'd rather take that then waste my own bandwith on p2p.
Some of the security threats to zoom are real of course, but I couldn't care less if Microsoft uses telemetry or whatever if I get a good service in return. I log into 20 different things with Google and Facebook and Microsoft already
Did anyone use Firefox? There's a fairly significant issue with video simulcast in FF, and if anyone on the call broadcasts video on FF it will use significantly more bandwidth than users on Chrome/Chromium-based browsers.
Tbh zoom on Linux is utter garbage. Every time I join a meeting, my CPU goes into deep frying territory. It's like compiling on heroin. In all fairness skype has been the most reliable for me so far, with jitsi being a close second.
Jitsi uses WebRC, so it's p2p. It's great for 2 person calls, could be good for 3 as long as you all have good connections to each other, but doesn't and will never scale higher.
From the FAQ : "We are fortunate that our friends at 8×8 fully fund the project. 8×8 uses Jitsi technology in products like Virtual Office. The open source community and meet.jit.si service help to make Jitsi better, which makes 8×8 products better, which helps to further fund Jitsi. This virtuous cycle has worked well in the past and should continue to for many years to come."
If Facebook would be ads-free, free, and open-source, would you use it? I'd be scared as hell. Imagine this line:
> We are fortunate that our friends at GoodCorp fully fund the project. GoodCorp uses Facebook technology in products like GoodCorp Social. The open source community and meet.facebook.com service help to make Facebook better, which makes GoodCorp products better, which helps to further fund Facebook. This virtuous cycle has worked well in the past and should continue to for many years to come."
And keep in mind that Jitsi seems like a more resource-hungry product (real-time video).
Sorry, I thought this is obvious, but I guess I have to re-state my question. The business model is unclear to me, they don't even make money on ads like Facebook, so it might be something worse.
What's the point for them to put all the money in?
Doesn't make sense to me, sorry. I imagine paying for servers to run free Jitsi for all the people is tens of thousands of dollars per month (if not hundreds). Are you saying that it makes more sense than hiring additional developers for that money?
I don't think it's quite as expensive as you might think. Unfortunately I don't have sources right now but from memory the server component mostly handles session management.
Regarding the official Jitsi meet site: "On a plain Xeon server (like this one) that you can rent for about a hundred dollars, for about 20% CPU you will be able to run 1000+ video streams using an average of 550 Mbps!"
Yeah, that'd cost you a substantial amount, probably more than paying for a Zoom subscription. Now imagine someone is just paying for you, for free, no ads. Isn't that weird? All I'm saying.
I am a Linux user and get it. What I don't get is if Linux.Org would start paying my AWS bills, explaining it by saying "it makes Linux better by more people using it". Don't you see an obvious strangeness here?
I understand not signing on Windows — it's a nightmare of incompetent, but expensive CAs, and unusable poorly documented mostly-broken tooling from the '90s. And in the end it hardly does anything, as you still get the executable blocked for a month.
But for macOS it's way easier, and more needed. It actually silences the scary warnings. It's even a real security improvement, as you get your app's keychain protected.
> And in the end it hardly does anything, as you still get the executable blocked for a month.
This is very much not true - if you have unsigned executables for an app of any scale, 3rd party AV will be extremely Unkind to your app, especially if you try to do updates. Also, how long your app gets blocked depends on how many downloads you get, if your app is popular it can be unblocked in a matter of hours, and once a download URL is deemed trusted, this is largely a non-problem.
Also, while I'll 100% agree that CAs on Windows are a nightmare, the tooling is extremely straightforward, signtool.exe takes your cert file, a password, and an executable, then signs it.
Except when the signtool.exe defaults to SHA-1, generating a signature that Windows won't accept. And then you need to add an arg for a timeserver. And args in a wrong order just silently generate a useless signature. And documentation for all of it is mostly from IE5.5 era, fragmented over several unfinished reorganizations of MSDN.
And tooling for managing the certs is another pain. Mine required entering a PIN from a GUI every time certs were touched, so I couldn't automate the builds.
Isn't Jitsi co-developed/sponsored by 8x8? An Apple developer account costs 99 per year. If the money is a problem, a lot of people would probably donate some amount if that helps getting signed releases.
At any rate, I think having unsigned binaries that are not notarized introduces additional hoops for non-expert users, since macOS requires signed bundles by default (which is a good thing!).
If by "hoop" you mean "workaround," yes. But normies are used to starting applications by double-left-clicking them, and there's nothing in the error message that appears after that indicating it can be worked around. Unless the normie thinks to ask a friend or the internet how they can go ahead and open the app anyway, they'll never find out about it.
To come at it from another direction, why is it your users' responsibility to work around your own cheapness/laziness? Just front the $100 and sign your damn app, especially if you're making money with it.
As Cyberdog says, the hoop is that a lot of regular users do not know about.
Moreover, signatures and notarization are there for a reason. Code signing makes it more likely that the bundle was not tampered with. Apple can revoke the certificate if the developer key leaked. Notarization will catch at least some forms of malware.
I refuse to run unsigned code (with one exception), because it decreases security significantly. There have also been severe incidents in the past with unsigned code, e.g.:
This is just one of my guess here. If you look at the commit history the project doesn't look like being the main focus. Code signing is not as streamlined as Let's encrypt, the money part makes it bumpy, so I'm not surprised.
Not sure I understand your offerings. You seem to suggest that you offer code signing without an Apple Developer subscription? So are you using your own certificates to sign your clients’ code? If that’s the case it sounds like you’re probably breaking TOS and opening up your clients to immense risk: one client’s abuse results in all clients’ apps revoked.
Unless free actually means a cash allowance (which would be very generous), I don’t see how this would work. I’m certainly not gonna let someone else register and pay for an Apple Developer account on my behalf.
It costs $100 a year to sign Apple programs (last time I was doing it). Jitsi has a corporate sponsor. Nobody involved with Jitsi could swing it? Really?
I've tried it before, but it seems to be only usable with the instance hosted at meet.jit.si. When I try to connect to any other instance, I'm just getting the error "external API not enabled". Sounds like there is some default configuration that prevents this from being used with most selfhosted instances.
I want to love Jitsi, I really do. But the 'Quick Install' of the server failed for me. So I tried the hosted service and it doesn't work in Firefox. Jitsi needs to work harder on ease of use.
Where did you find the quick install and what OS were you using? I was trying so hard to find a Jitsi server install for Windows but the only thing I found was a jar+batch file process that I couldn't connect to once I finally got it running.
Before the "We hate Electron" crowd gets here - congrats to all involved on this release: so far it works great, the UX is simple enough for anyone to use, it's open source and most importantly - it isn't Zoom.
I'm part of the crowd that dislikes the trend to use electron for everything. I have 8gb of soldered Ram on my laptop, and will be forced to buy a new machine because I'm swapping like crazy now. My workflow hasn't changed. My activity hasn't. But 2 years ago, Firefox and Virtualbox were the only hogs, for reasons I could accept. Now, dynalist, stremio, discord, signal, pulsesms and vscode are added to the mix.
However, I understand that said apps may have not existed without Electron at all.
And especially, for jitsi, I think it makes perfect sense. If you are going to create an app that does video, audio and web rtc, it would be silly not to use a battle tested browser engine that does all this already.
Besides, having contemplated the state of UI in a world were you have a bazillions of combination of hardware type + screen format + OS kernel + OS version, I have to say Electron doesn't have much competition.
What are you going to do? QT? Phone support is abysmal and it's a pain to package. Kivy? Super slow, almost no widgets. Flutter ? Uses a niche language with a very small ecosystem and an unknown life expectancy.
I probably would go with the later, but I can't blame people for taking the easy road.
> If you are going to create an app that does video, audio and web rtc, it would be silly not to use a battle tested browser engine that does all this already.
I think you mean "create an app that does video, audio USING web rtc".
Plenty of native desktop/mobile apps do video/audio/text without embedding a browser.
> Plenty of native desktop/mobile apps do video/audio/text without embedding a browser.
Yes and it's a pain to do: format is limited, packaging is hard, ability to manipulate/embed the video is annoying. In fact, most apps doing that ship ffmpeg and/or vlc and call it a day. The browser gives so you much for free.
Most attacked, I could believe. Most compromised, I'm not so sure. Browser teams ship out new versions very regularly, it's nothing compared to vulnerabilities contained within the first release of Windows XP, for example.
Is it? ffmpeg as a library can decode about anything you want and put it in a buffer in less than 100 lines. Is that not for free? It's a self contained shared library.
Electron apps have the slowest interfaces on anything I've seen, lots of times each click of a button or menu has lag on a very solid computer. Who wants to have a program doing video embedded in a painfully slow interface?
What do you mean by lifecycle and fallbacks? Also you just said that building in multimedia was the problem and when I point out libraries are easy to use and modular you say that C++ is the problem.
I think you are giving too much credit to people using electron. It really seems to be mostly people who haven't really looked at their options avoiding native languages at the expense of the user. If all someone knows is javascript and they don't really care about their users' lag or resources, then electron is any easy choice.
When I buy a computer, the first thing I look for is extendable memory. If I can't easily plopp in at least double the RAM than it has, I'm not buying it. Got bitten already enough with the old 286+ era computers. Since then the memory consumption has been increasing the whole time until now you can't even start your editor without 1-2 GB disappearing. Want a browser too? That's another GB at least. A chat program? Another GB. The times where a chat client was 40 kb are long gone, now it has to have emotes and embeded movies at a minimum.
I had the freakish opposite experience where I went from an 8gb linux machine that was scraping the top of that to a 16gb machine at the same time I switched from openSUSE's standard release to their rolling release (Tumbleweed). My memory usage immediately dropped by 30-40% and the bits that didn't were all Electron-based. Even Waterfox with 4K tabs dropped significantly. I have no idea how they managed it, but it was a pleasant surprise at the same time it highlighted that if you use a lot of Electron apps there are no good options.
Imagine when Windows 10 is "updated" to essentially be a chromium browser with typescript used for all UI and builtin utilities. In such a case only special windows store apps are able to be installed... this is the future Microsoft and Google want for us.
I would imagine such a monstrostiy would be so slow with even 32gb that we would have to pay for extra cloud-based services to do menial tasks like edit documents.
I bought a mac with 32gb in 2013, figuring this would be good for a long while... these days with mem usage constantly hanging around 28-30gb, I'm now choosing between 64 and 128 for the next machine (with 128+ only being available in apple's 'pro' line...).
Without Electron many of programs/apps would not be available on Linux. I'm happy Electron exist and we have overall more Linux desktop compatibility in an easy way. Electron fulfilled what Java has envisioned, it's only bad there is not an universal ONE runtime below that all (although there are Electron bugs on github where this is worked on).
Any previous solution to do UI: QT, GTK, WX, etc were cross plateforms.
I don't think that's it.
Electron make it easy, if you know front end dev, to do an app. It's easy to package as well.
I don't know if you tried to design a beautiful QT app, but it's hard. A beautiful QT app with medias capabilities ? Extra hard. Packaging that? A royal pain.
> Now, dynalist, stremio, discord, signal, pulsesms and vscode are added to the mix.
So your workflow has changed. You added additional tools to it. These tools have always been electron. You don’t have to use them. There are alternatives.
The people behind these tools have decided that they target an audience you don’t belong to. You are of course free to ask them to change the audience, but you are not entitled to that
These are all just more recent variants of tools which we have always used, e.g. some chat apps, some editor, etc. In that way, not much has changed. It make sense though to move on to newer tools, which are basically the same tools though, just updated, maybe more modern features, not necessarily more features in total.
And maybe offering these modern features is so much easier using the electron platform that offering the features based in something else is not worth doing.
There must be a benefit for developers for them to chose electron. And that benefit for developers will have an effect for the users in either more features, quicker rollout or more supported platforms.
I have a suggestion for you that helped me. Try running Android OS like Prime OS (https://primeos.in) in virtual box and you can run those Android apps with low memory usage(I'm assuming that they offer the same experience in Mobile or that you are okay with limited functionality). I set this up for my wife as she kept complaining that her 8 Gb RAM was quickly consumed by Chrome, Slack, Spotify and other apps.
Now the virtual box memory limit is set at 3 GB and she has no complaints. Obviously this is not for power users but it helps a lot when there is a severe shortage in memory
I though about it, as a workaround. But realistically:
- my base ram consumption is 2Gb, so it would make 5gb with the VM, giving me 3gb for: firefox, and IDE, thunderbird, telegram, stremio, libreoffice, nautilus, veracrypt, liferea, gnome calendar, keypass, dev tools such as linter/dev servers/formatters, tilix, veracrypt, youtube-dl, jupyter, other VM I use for work... Even if I don't use them all at the same time, that's not a lot real estate. It used to be enough. When I used sublime instead of vscode, didn't have 4 communications apps and so on. You gotta hand it to the electron community: their software do bring good features.
- The ergonomics would be terrible for certain softwares. For chat, it would be alright (no notification is ok with me), but for stuff like dynalist, I need to be productive
- It's slow to use. You can feel the reaction time with every action. Android is slow in itself, but in an emulator, you want chain too many actions
Yes if people used it, but no because people would probably not.
One of the reason electron is so easy to package: it creates a big blog of statically linked everything. If you start having to play the packaging game correctly, you get back to the same problems other run time had.
Does it use a new instance for every app, or it loads the engine once and reuses some of it for every instance?
ie. can Electron be made to work like a system shared library, similar to GTK/Qt ?
The only improvement I see is to move away from electron. For alternatives everyone should take a look at Revery-ui written in Reasonml. Its starts in milliseconds, few megs of RAM usage, very low CPU usage and has most of the modern developer experience associated with Electron!!
MS probably knows. VSCode without any extension is pretty reactive and light. It becomes heavy when you have 20 tabs open with linters, languages servers, formatters and so on.
But your comparison is also not really fair, since you assume everything runs and is stored on your local computer. This is not the case anymore at all.
Plus, the web browser is probably the first application that is started by a user.
Following applications all run in my browser:
- email
- video conferencing with screen sharing
- (persistent) chatting
- Office applications (word processor, spreadsheet, ...)
- photo storage
- games
- development sandboxes
- ...
In fact most Apps I have on my phone could just be PWA's.
I'm not saying we should all go web, but I'm saying that most things where you want to use electron, you could let it run on the web.
In principle, there is no reason why Electron must be so memory inefficient, right? We could optimize it in a way that it only loads resources it really needs. So in case of a video chat app, it would need video, audio, web RTC, a bit of HTML and JS. That should be possible to fit in a few MB of RAM. Only because Electron supports much more doesn't mean it must take so much memory.
Maybe it would make sense that we just focus on optimizing Electron for this case. That might take a bit of effort, but that effort might be worth it.
Another route is to share the same resources between apps, i.e. make a progressive web app. I haven't used the Jitsi desktop app so I can't speak to it, but I'd be curious to know what features are missing from PWAs that mean a native wrapped Electron app is necessary.
But being more specific here: What exactly are the shared resources? The binaries? That could maybe save a couple of hundred MB but this is maybe still not the biggest part. The remaining memory is probably sitting there in memory allocations of JS or so, and I don't think that can be shared.
> The remaining memory is probably sitting there in memory allocations of JS or so
I'm not so sure about that. 5 Electron apps takes up far more memory than 5 tabs open in your browser because there are 5 copies of all the other browser resources. I don't know exactly what they are but anecdotal observation of using Slack and similar apps as browser tabs shows much less memory use. It makes sense: the browser rendering engine and JavaScript engine are going to occupy memory themselves.
Yes, as evidence for this web browsers sitting at an empty new tab page are generally still using at least 100-200mb to do nothing. The likelihood that most of that is not the part that's most vital and feature rich is low.
It's a excellent software for managing things to do, and I pay monthly for it. It is very efficient to use, works offline and on mobile seamlessly, use a JSON format for storage, and can export in a standard format to avoid locking (even on the free plan).
I use it to manage things to do, listing, etc., but I would not use it for taking notes, IMO. The format doesn't look great for it.
Anyway, the free plan is good enough to try it on, and the customer support excellent.
I quickly played with the demo. I'm more a note-taking kind of guy than a todoist. I love the UI but yeah, since everything is a list it's not for me. For my use, Google Tasks is enough for me.
I've tried Evernote, Boostnote, Simplenotes, Notion, even a bunch of markdown files inside a Github repo and so far nothing was 100% perfect for me. :)
- I can use whatever file format I want, mix in images, odt, pdf, md, etc
- I can backup and sync
VSCode is a pretty good editor to manage it all, and I played with the idea of creating an app with the new editor view feature of the last version just for that. Support some metadata, create an automatic encrypted sync server and that's it.
Most of the RAM usage when it comes to Telegram (and other IMs I guess) is media autodownload. Once you turn it off - the problem is solved (same for the battery life on mobile)
It wasn't anything like the original Slack app last I used it a few months back. Has this changed? It doesn't have a keyboard shortcut to jump between unread channels as a basic example. Or hiding read channels, so I've got a huuuge list.
Yup. Telegram Desktop[1] and the web client[2] are separate projects.
The desktop client is still quite heavy on resources on Linux, and needs a restart every now and then.
I have exactly one electron app (VSCode) that I need for my regular daily work. Everything else I shut down when I don't need it. Then I look at my coworkers who have dozens of apps running at the same time and complaining that their laptop is slow, and I only shake my head…
Card carrying member of the unnecessarily complicated stack skeptic's club here, but this is something Electron actually makes sense for. This is one of the few cases where bundling a complete WebRTC stack makes sense, because it's actually being used, and bundling the web browser could potentially make permission management a bit easier which is probably one of the remaining usability problems.
Couldn't they rip-out the WebRTC stack - leaving out the RAM-hungry parts of Electron/Chromium/V8/etc that aren't relevant to desktop applications (e.g. aggressive in-memory caching, process isolation, etc)?
As much as we all have strong opinions about Electron, surely someone who is able to make a solidly built "DOM+CSS+JS+Optional extras" version of Electron would be make _bank_ overnight by servicing and consulting for it? I know lots of companies would love a build of Electron with a smaller attack-surface, for example.
I just wonder why an electron like chromium library isn't just provided by default by Windows and Linux. Then it could be updated by the system vs. each app updating individually and be much more secure.
I suppose one issue is that you have to either be very good with backwards compatibility or at least support having a single instance of multiple different versions of the runtime installed side-by-side (e.g. similar to .NET Core).
There is also this.. 'Exploring lighter alternatives to Electron for hosting a Blazor desktop app' [1], which builds upon 'webview' [2].
Just one example: the Jitsi Meet Electron app e.g., allows you to remote control a screen, if screen owner allows. This makes it a replacement for e.g. TeamViewer, VNC or so...
Ok but besides that one feature, almost every other feature can be done in Chrome. I run Slack in Chrome. Why not? Because of some features I don’t need?
I like native apps on my machine. I have enough tabs open in chrome as it is. And when I want side-by-side views of a Slack tab and some other webpage, those tabs turn into mutliple chrome windows. Then I'm alt-tabbing between Chrome - Chrome - Chrome - Mail - IDEA - Chrome - Terminal. Why is it so bad to install an app? This has been the default since computers became a thing, so what's the argument for sticking everything into your browser?
Why do people hate Zoom so much? I just received an email today from Zoom outlying all the fixes they just released.
They went from 10m users/week to 200m/week in less than one month.
So what they struggled? Most products would struggle with that kind of ramp up. They owned up to it and fixed pretty much all the complaints. And they're providing a valuable service to the world, most of it for free.
Most problems they had (at least those reported on) were not really tied to the number of users though, that would be quite excusable. The criticism was mostly poor security[1] due to bad decisions in the first place.
It mostly highlights that in order to rush the product out of the door many shortcuts were taken and security shouldn't be one of them in this day and age.
No. I don't trust Zoom. I don't like that people like you apologise for them while they continue to make choices that actively endanger users.
I don't like their business model, and I don't like that I'm forced to use it to interact with people. I don't like that I can't verify it's doing what it says it's doing and am actively prevented from doing so. I don't like Zoom and I don't like that I can't choose to not install their spyware because people who don't know any better and don't have any way to protect themselves keep installing it and forcing me to use it.
No. I won't stop hating Zoom until I - and the people who don't know how Zoom is hurting them and so use it anyway - can be free of it and the people who make it so awful.
This has absolutely nothing to do with where Zoom is developed or by whom. It is the stated privacy policy and the software engineering practices to which the company adheres - and the security best practices to which they do not - which are abhorrent to me. This isn't about tech. This isn't about nationality. This is about a social tool being used to exploit people and the network effects that has on others who may have no choice.
That's why Jitsi Meet is important. It is everything Zoom isn't - while still accomplishing nearly everything Zoom attempts to accomplish while exploiting its users. That's why it's important.
Yes, you can trust - so long as you always verify while trusting.
However, there’s a big “but”. The documentation is abysmal. I’m sorry but that’s the cold hard truth. It’s been a nightmare to understand the pieces working while also using their libraries. Incredibly hard to read, and incomplete, docs. I’ve had to refer to the source to try figure things out most of the time. I say this because I think there’s soooo much potential there if it was more accessible. If you’re from jitsi and are keen for some good and critical feedback then hit me up, I’d love to help you out.