The organizers and other volunteers hang out in the #emacsconf IRC channel on If you would like to get involved and help us out with the planning, come by the IRC channel and say hi!

We will be collecting various ideas and plans for organizing the conference and adding excerpts from #emacsconf logs to this page.

Current plans for infrastructure

The event will probably be comprised of two main parts: the video-call part, and the live-stream part. We are separating these two, both for speed/overhead/bandwidth concerns (if a large number of people decide to “join the video-call” to watch), as well as moderation and distraction concerns (having to moderate a large number of people in a video-call, where only one of them is supposed to be speaking at a time).

So, we will use one series of software for the actual video-calls, whereby speakers would take turns joining the call and deliver their presentation, and another series of software for streaming the video-call for everyone else to watch live.

  1. Video-calling: we currently have two candidates for the video-call software, namely Jitsi Meet, Jami; under Apache-2.0 and GPLv3+ respectively. I have not yet tried Jami, but Jitsi Meet seems to work fine in Firefox and Trisquel’s Abrowser (without LibreJS). Sadly, Jitsi Meet currently doesn’t have explicit license headers on their site, so it seems that LibreJS blocks their JS.

    I will be opening a bug report for Jitsi Meet asking them to add license information to their hosted version of Jitsi Meet so that LibreJS would allow their JS to run. If they decide not to, we could try and run a self-hosted instance, though then the challenge would be the inter-continental latency: I’m fairly sure Jitsi Meet’s hosted version at uses an array of servers across the globe to help reduce latency, and that’s something that we certainly can’t afford if we were to self-host.

  2. Live-streaming: this is the software most people (i.e. watchers) will be facing. We will likely use a combination of OBS Studio+Nginx+RTMP to capture the video call, and upload/stream it to our server, where people would then be able to either watch the stream in their web browser (similar to LibrePlanet’s embedded video player) or point their media player (such as VLC or mpv) directly to the stream and skip the browser entirely.

    Greg Farough helpfully provided me with a series of config files he had previously used for setting up live-streaming as I described above. I will be trying to set it up on our (well, my) server and test streaming. Since my server is a fairly small (virtual) machine, I’m thinking of asking the FSF sysadmins to see if they could kindly help out with extra computing power and/or bandwidth on the day of the event if needed.

Older notes for infrastructure

We need to decide on a good way to host the conference. An important priority here is to use as much Free Software for this as possible, ideally 100%.

At the moment, it seems Jitsi Meet is our best bet. Let’s see if we can self-host it and if it’s usable with limited resources. If not, we might have to use the flagship version hosted at

Bandwidth-wise, it seems that Jitsi’s videobridge may not be a bottleneck [1]. It seems using Jitsi could be feasible.

At some point, we should probably contact the admins of and verify that it is okay to run a conference on their site. We should also obviously try it out thoroughly well in advance of the conference.

Other candidates?

- maybe ask Nextcloud to sponsor some talk/video hosting? - maybe ask the people at for advice?