5 ms·

Show HN: Galène Videoconferencing Server

132 points by jech 6y ago

spicyramen 6y ago
Any comparisons vs McuWeb or jitsi?
- cies 6y ago
  I thought the same. Really cool they list the alternatives on the project page. But a little something on why they did not use the alternatives but built their own would be very helpful for those evaluating the options.
- jech 6y ago
  Jitsi is a great piece of software, as are the other alternatives listed on the web page. The opposition is not with other self-hosted videoconferencing solutions, but with cloud-based systems that impose restrictive usage conditions. How do we convince people to switch to self-hosted solutions? I think that part of the solution lies in making them easier to deploy: ideally every high school, every community college should be able to have their own videoconferencing server, which can be used for lectures, for practicals, for student-teacher meetings ("office hours"), and hopefully for student socialisation (although in my experience students tend to prefer Discord, notwithstanding their outrageous usage conditions). Galène is designed to be as easy and cheap to deploy as reasonable. It also has a number of features that make it useful for practicals (sharing multiple windows simultaneously, automatic creation of subgroups), which we found very difficult to organise online during the first French lockdown.
  - Reventlov 6y ago
    Do you envision having a way to administer rooms like muting people or kicking users, for example ?
    - jech 6y ago
      That's already implemented. Connect as an administrator and type /help in the chat window. (Your weapons are /warn, /mute, /kick, and /lock, in increasing order of severity.)
Sean-Der 6y ago
Congrats on the launch jech! These are the things that have made me really excited about Galène. If you are doing broadcasting/teaching you really can't beat it. * The build/deploy is INSANELY easy. `go build` and a certificate. * UI is a joy to use. Load it up, no frustrating loading screens or spinners. A clean layout that effectively uses the screen real estate. * UI/Backend is decoupled and documented. Read `README.FRONTEND` it clearly lays out how to bring your own frontend. * Built in a way you can learn from. The code is clear and concise, I have learned a lot from reading it and brought back ideas to my own work!
- 5Qn8mNbc2FNCiVV 6y ago
  This comment looks like it's bought
  - jech 6y ago
    Sean is the benevolent dictator of the Pion WebRTC library (https://github.com/pion/webrtc/ https://github.com/pion/webrtc/), which is at the core of Galène. He was aware I'd be posting on HN, but we didn't arrange anything in advance, if that's what you're implying.
  - teraflop 6y ago
    From the HN commenting guidelines: > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.
ortenheim 6y ago
Very interesting. How does it work scaling? Possible to have one loadbalancer with multiple servers? With autscaling? Or only works with one server for now?
- Sean-Der 6y ago
  From the README he has these numbers For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core Scaling wise what are you trying to do? * You can put different rooms on different servers. They don't have to aware of each other. * If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers. * If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.
  - jech 6y ago
    > You can put different rooms on different servers. They don't have to aware of each other. Yes. You could then use a reverse HTTPS proxy to route each client to the right instance of Galène. For very large groups, that need to be split between multiple servers, you'll need to wait until we implement server federation (distributing a group over multiple, geographically distant servers). I know for a fact that Jitsi implements federation, not sure about Ion-SFU.
    - Natfan 6y ago
      How would I actually go about doing this? By default I can see that the process binds to localhost:8443, which is not accessible via other devices. Running the following command doesn't seem to work either: galene -http 0.0.0.0:8443 Using a nginx server as a reverse proxy, I have the following that works for HTTP but not WebSocket: server { server_name galene.domain.com; location / { proxy_pass https://127.0.0.1:8443/; proxy_set_header Host $host; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/natfan.io/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/natfan.io/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Thoughts? Happy to move this to Github if that's easier too.
sylwester 6y ago
Great, works out of the box. I'd add an anonymous option to the login, even though you can leave the password empty. Also, an indicator if TURN is used and if it's non-encrypted or encrypted would be great.
- sylwester 6y ago
  Also, a chime when someone is joining would be a nice addon.
  - kerneis 6y ago
    Remember it was initially implemented to support giving lectures to tens of students, who may join late or leave early. Having to teach remotely, let's try to at least not reproduce the annoyance of the physical world with the noise of the classroom's door ;-) (I agree that an optional sound would be nice.)
- jech 6y ago
  > I'd add an anonymous option to the login Good idea. I'll check with Alain (the UI guy). > if it's non-encrypted or encrypted It's always encrypted (WebRTC doesn't support plaintext communcation). If we ever add an option for end-to-end encryption, we'll add an indicator.
  - pmaynard 6y ago
    What protocol would you choose for end-to-end encryption, Double Ratchet Algorithm, or another lightweight one?
    - jech 6y ago
      I haven't thought about it seriously, but I was thinking about simply using a shared key (PBKDF2, since that is implemented in the browser), with a symmetric cipher and HMAC. To tell the truth, I haven't seen much demand for end-to-end: this is a web application, so an attacker who controls the server can simply serve Javascript with a backdoor.
bilekas 6y ago
This is really cool, I havent found many solutions like it before while looking! Nice. > This server is used in production, please don't overload it. HN Might inadvertently cause that! :)
- jech 6y ago
  That's okay — teaching is over until January, and at any rate students are a forgiving user base :-)
kodablah 6y ago
Nice. I have been toying in this space myself and programmatic alternatives to the existing solutions I think are the way forward. The future features are exactly what I'm looking for. Namely simulcast support to help bandwidth limited clients and server scalability/redundancy especially in a WAN scenario.
alexchamberlain 6y ago
This is cool. Some random thoughts/feedback: - it would be good to document/visualise the different components. AFAICT coturn is used to connect peers; what is galene responsible for? Signalling and room management? - A big, clear link to the code on Github is always nice
- jech 6y ago
  Galène is not peer-to-peer: it's a traditional centralised server, where all media traffic goes through Galène. TURN is only used if the user's network blocks the UDP traffic between the client and Galène (TURN can use TCP, and can run on an unblocked port such as 443 or 1194). Before Galène, I experimented with a pure peer-to-peer system, with end-to-end encryption. I found it to be too unreliable for group communication: with just 5 people in a group, you need to establish 10 peer-to-peer WebRTC flows, and the likelihood that all of them work well is essentially zero.
  - api 6y ago
    Thank NAT for that. I wonder how many hundreds of billions of dollars in hidden overhead it costs us annually by making peer to peer unreliable and complicating everything. Then throw in all the power consumed by all the cloud infrastructure we wouldn’t need. “Null” in languages like Java has been called a trillion dollar mistake. NAT is probably worse.
    - zepto 6y ago
      Without NAT we’d have run out of ip addresses long ago.
      - tinus_hn 6y ago
        So we would have transitioned to IPv6 already; it’s not necessarily a bad thing. We’re going to run out regardless.
      - api 6y ago
        Good. It would have forced the V6 upgrade, which is the right thing and makes this problem go away forever. It would have been cheaper overall too.
daimoc42 6y ago
Great work, it really nice to see an sfu implemented in top of pion. Could you explain a little bit how you managed the bandwidth and the nack request in your 1 to N use case ?

132 points by jech 6y ago

spicyramen 6y ago

Any comparisons vs McuWeb or jitsi?

cies 6y ago
I thought the same. Really cool they list the alternatives on the project page. But a little something on why they did not use the alternatives but built their own would be very helpful for those evaluating the options.
jech 6y ago
Jitsi is a great piece of software, as are the other alternatives listed on the web page. The opposition is not with other self-hosted videoconferencing solutions, but with cloud-based systems that impose restrictive usage conditions. How do we convince people to switch to self-hosted solutions? I think that part of the solution lies in making them easier to deploy: ideally every high school, every community college should be able to have their own videoconferencing server, which can be used for lectures, for practicals, for student-teacher meetings ("office hours"), and hopefully for student socialisation (although in my experience students tend to prefer Discord, notwithstanding their outrageous usage conditions). Galène is designed to be as easy and cheap to deploy as reasonable. It also has a number of features that make it useful for practicals (sharing multiple windows simultaneously, automatic creation of subgroups), which we found very difficult to organise online during the first French lockdown.
- Reventlov 6y ago
  Do you envision having a way to administer rooms like muting people or kicking users, for example ?
  - jech 6y ago
    That's already implemented. Connect as an administrator and type /help in the chat window. (Your weapons are /warn, /mute, /kick, and /lock, in increasing order of severity.)

Sean-Der 6y ago

Congrats on the launch jech! These are the things that have made me really excited about Galène. If you are doing broadcasting/teaching you really can't beat it. * The build/deploy is INSANELY easy. `go build` and a certificate. * UI is a joy to use. Load it up, no frustrating loading screens or spinners. A clean layout that effectively uses the screen real estate. * UI/Backend is decoupled and documented. Read `README.FRONTEND` it clearly lays out how to bring your own frontend. * Built in a way you can learn from. The code is clear and concise, I have learned a lot from reading it and brought back ideas to my own work!

5Qn8mNbc2FNCiVV 6y ago
This comment looks like it's bought
- jech 6y ago
  Sean is the benevolent dictator of the Pion WebRTC library (https://github.com/pion/webrtc/ https://github.com/pion/webrtc/), which is at the core of Galène. He was aware I'd be posting on HN, but we didn't arrange anything in advance, if that's what you're implying.
- teraflop 6y ago
  From the HN commenting guidelines: > Please don't post insinuations about astroturfing, shilling, brigading, foreign agents and the like. It degrades discussion and is usually mistaken. If you're worried about abuse, email hn@ycombinator.com and we'll look at the data.

ortenheim 6y ago

Very interesting. How does it work scaling? Possible to have one loadbalancer with multiple servers? With autscaling? Or only works with one server for now?

Sean-Der 6y ago
From the README he has these numbers For one-to-many communication (lectures), the behaviour is linear, and Galène should be able to serve about 400 participants per core Scaling wise what are you trying to do? * You can put different rooms on different servers. They don't have to aware of each other. * If you want to scale out the broadcast case you will probably want to follow the ingest pattern. Have one server forward to n with viewers. * If you want really large conference calls you will need to think about the experience. Residential internet can only accept so many incoming feeds. Do you want to enable/disable them on the fly? Do you want to have 'active speaker' only view etc.. not just a scaling problem but also UX.
- jech 6y ago
  > You can put different rooms on different servers. They don't have to aware of each other. Yes. You could then use a reverse HTTPS proxy to route each client to the right instance of Galène. For very large groups, that need to be split between multiple servers, you'll need to wait until we implement server federation (distributing a group over multiple, geographically distant servers). I know for a fact that Jitsi implements federation, not sure about Ion-SFU.
  - Natfan 6y ago
    How would I actually go about doing this? By default I can see that the process binds to localhost:8443, which is not accessible via other devices. Running the following command doesn't seem to work either: galene -http 0.0.0.0:8443 Using a nginx server as a reverse proxy, I have the following that works for HTTP but not WebSocket: server { server_name galene.domain.com; location / { proxy_pass https://127.0.0.1:8443/; proxy_set_header Host $host; } listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/natfan.io/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/natfan.io/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } Thoughts? Happy to move this to Github if that's easier too.

sylwester 6y ago

Great, works out of the box. I'd add an anonymous option to the login, even though you can leave the password empty. Also, an indicator if TURN is used and if it's non-encrypted or encrypted would be great.

sylwester 6y ago
Also, a chime when someone is joining would be a nice addon.
- kerneis 6y ago
  Remember it was initially implemented to support giving lectures to tens of students, who may join late or leave early. Having to teach remotely, let's try to at least not reproduce the annoyance of the physical world with the noise of the classroom's door ;-) (I agree that an optional sound would be nice.)
jech 6y ago
> I'd add an anonymous option to the login Good idea. I'll check with Alain (the UI guy). > if it's non-encrypted or encrypted It's always encrypted (WebRTC doesn't support plaintext communcation). If we ever add an option for end-to-end encryption, we'll add an indicator.
- pmaynard 6y ago
  What protocol would you choose for end-to-end encryption, Double Ratchet Algorithm, or another lightweight one?
  - jech 6y ago
    I haven't thought about it seriously, but I was thinking about simply using a shared key (PBKDF2, since that is implemented in the browser), with a symmetric cipher and HMAC. To tell the truth, I haven't seen much demand for end-to-end: this is a web application, so an attacker who controls the server can simply serve Javascript with a backdoor.

bilekas 6y ago

This is really cool, I havent found many solutions like it before while looking! Nice. > This server is used in production, please don't overload it. HN Might inadvertently cause that! :)

jech 6y ago
That's okay — teaching is over until January, and at any rate students are a forgiving user base :-)

kodablah 6y ago

Nice. I have been toying in this space myself and programmatic alternatives to the existing solutions I think are the way forward. The future features are exactly what I'm looking for. Namely simulcast support to help bandwidth limited clients and server scalability/redundancy especially in a WAN scenario.

alexchamberlain 6y ago

This is cool. Some random thoughts/feedback: - it would be good to document/visualise the different components. AFAICT coturn is used to connect peers; what is galene responsible for? Signalling and room management? - A big, clear link to the code on Github is always nice

jech 6y ago
Galène is not peer-to-peer: it's a traditional centralised server, where all media traffic goes through Galène. TURN is only used if the user's network blocks the UDP traffic between the client and Galène (TURN can use TCP, and can run on an unblocked port such as 443 or 1194). Before Galène, I experimented with a pure peer-to-peer system, with end-to-end encryption. I found it to be too unreliable for group communication: with just 5 people in a group, you need to establish 10 peer-to-peer WebRTC flows, and the likelihood that all of them work well is essentially zero.
- api 6y ago
  Thank NAT for that. I wonder how many hundreds of billions of dollars in hidden overhead it costs us annually by making peer to peer unreliable and complicating everything. Then throw in all the power consumed by all the cloud infrastructure we wouldn’t need. “Null” in languages like Java has been called a trillion dollar mistake. NAT is probably worse.
  - zepto 6y ago
    Without NAT we’d have run out of ip addresses long ago.
    - tinus_hn 6y ago
      So we would have transitioned to IPv6 already; it’s not necessarily a bad thing. We’re going to run out regardless.
    - api 6y ago
      Good. It would have forced the V6 upgrade, which is the right thing and makes this problem go away forever. It would have been cheaper overall too.

daimoc42 6y ago

Great work, it really nice to see an sfu implemented in top of pion. Could you explain a little bit how you managed the bandwidth and the nack request in your 1 to N use case ?