Show HN: Jam, an Open Source Clubhouse

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Scout APM - Less time debugging, more time building
  • OPS - Build and Run Open Source Unikernels
  • SonarQube - Static code analysis for 29 languages.
  • GitHub repo jam

    Hi everyone,

    a few days ago @DoubleMalt, @mitschabaude and me did a one-day hackathon to see if we can get a minimal WebRTC based version of a Clubhouse-style "room" to work.

    Since then we added a TURN server, bug fixes ("can you hear me?") and a bit of ui polishing.

    Jam should run in any modern browser but the long-tail of browsers and operating systems is … long, so please let us know if it does not work for you, and what you are using. We want Jam to run if it can run. If your toaster supports WebRTC it might run Jam as well.

    We tried to keep the implementation fairly minimal, I'm sure there is more we can remove and simplify once we spend more time on it.

    Please give it a try and let us know what you think. Any thoughts, comments, feature requests, hosting-deploy-target requests etc etc highly appreciated.

    (for those who are not familiar with Clubhouse yet:)

    A room in Clubhouse (or on Twitter Spaces) is a bit like Zoom without video, without screen sharing and without text messaging.

    You see a grid of all the people in the room, who is speaking, who would like to say something (slow mute/unmute flashing), who is clapping (fast mute/unmute flashing) and that's it.

    Over the past few years I experienced what we all now call "Zoom fatigue". I just don't enjoy video calls. When the pandemic started it felt like even people who in the past were happy with phone calls also wanted to jump on Zoom calls. I'm glad that eventually slowed down again.

    I'm super excited about Clubhouse, Twitter Spaces and the activity around audio spaces and live calls.

    In hindsight it is fascinating how the ui for group phone calls on smartphones has not advanced much compared to the non-smart phones.

  • GitHub repo server

    screen sharing for developers (by screego)

    Amazing work! The WebRTC community needs something like this so bad. Not only will this push a bunch of users toward self-hosted/free software but will also inspire others to build cool things :)

    If/when you hit scaling challenges I would love to help! I maintain and You can see that with how screego[0] does it.

    Happy to help however I can (even if not using Pion!) One of the reasons I built it was so that I could put my TURN and Signaling server in the same process. It makes it way easier to tie your auth together for signaling+TURN. Then if you do go down the SFU route lots of interesting things you could do.


  • Scout APM

    Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  • GitHub repo WebRTC-Scalable-Broadcast

    This module simply initializes and configures it in a way that single broadcast can be relayed over unlimited users without any bandwidth/CPU usage issues. Everything happens peer-to-peer!

    Perhaps Scalable WebRTC could help you there? Pure client mesh without having to add more servers on your end to mix anything

  • GitHub repo mumble-web

    An HTML5 Mumble client

    Nice project. For server side mixing, how hard would be to integrate Jam with Mumble? There is a Github repository that does it:

  • GitHub repo bananaphone

    A bunch of bananas to call your friends

    Nice work! A colleague of mine did a similar thing in 2014 but it bitrotted terribly. Code is at

  • GitHub repo simple-peer

    📡 Simple WebRTC video, voice, and data channels

    Not an expert here but have some experience with it:

    Assuming that each peer is connected to every other peer via a mesh network [see this image for reference:], each outgoing stream (esp. audio / video) is likely going to be duplicated, per recipient.

    Scalability over a mesh network is fully dependent on CPU and network performance of all of the connected devices, and I'd doubt it could handle 12 participants if there is video involved, unless all participants are running relatively high-end and modern devices, with optimal network conditions.

    You'll need a SFU or an MFU running on the server to handle larger rooms, while enabling all connected devices to only have to send one output stream per media type, regardless of how many connected participants there are.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts