
Show HN: pion/ion, self-hosted conferencing software with single command deploy - Sean-Der
https://github.com/pion/ion
======
Sean-Der
Really excited to share pion/ion! It is a distributed RTC System written in
Pure Go and Flutter. It can be used for video conferencing, live streaming and
most other media streaming problems. It has a lot of interesting features, but
the ones that seem to excite people the most are.

* Distributed by default - Designed to allow running different workloads and scaling them out as you need

* Flutter and JS SDK - Ready to be used on Web, Android and iOS!

* Designed to be modified - Modify the UI/Backend so you can have custom experiences for your use cases. As long as you satisfy public APIs any piece can be swapped.

* Easy to deploy - docker-compose with LetsEncrypt support. Spin up a conference server with on command

* Performant - You can run multi person conference calls on AWS free tier instances

* A joy to develop - Pure Go means quick builds, and a code base that anyone can contribute too!

* Community owned - The only thing driving the project is the contributors and users

We also plan on adding lots more, with some of the following in our road-map
already. [0] If you are interested in learning more about some of this stuff,
this is a great chance! It is really rewarding seeing all the innovative
things being built.

* RTMP Ingestion

* SIP Support

* Server Side Processing/OpenCV

* Record calls

We would also love to have you! If you are interested in working on this
project you should join our Slack[1]

[0]
[https://github.com/pion/ion/projects/1](https://github.com/pion/ion/projects/1)

[1] [https://pion.ly/slack](https://pion.ly/slack)

------
armagon
This sounds interesting, but I can't tell what it is -- there's too much
terminology I'm not familiar with. The list of features is all tech-centric
and doesn't step back and say what the thing does.

I think it is a self-hosted video conferencing solution, which sounds awesome,
but I'm not certain of that. I assume "RTC System" is not a real-time clock.
I've heard of Go, and Flutter sounds like some sort of Web UI system.

Can anyone explain this a little more simply, please?

~~~
Sean-Der
You are exactly right, it is a self-hosted video conferencing system. It was
designed in a way that lets you do some extra stuff that could be nice (like
pull in an external video feed)

I will work on making the README more friendly! If anyone else is interested I
would love help, working in this space has made me biased so I tend to write
thing for myself.

~~~
armagon
Thanks, Sean-Der.

And, that's a good point. The curse of knowledge is real :-)

------
0az
I've been keeping an eye on the pion/ion ecosystem, since I like the idea of
an independent WebRTC stack that doesn't essentially bundle Chrome's
implementation, and I've toyed with the idea of self-hosting a conferencing
system.

It looks like a lot of progress has been made since the last time I visited
the repo.

Congrats.

I suppose it's time for me to learn Go.

~~~
Sean-Der
Thanks :)

I think it is super important to have multiple implementations of important
protocols (like WebRTC, DTLS and SCTP). It brings more resiliency, and it
helps people learn them. It seems like in tech a lot of things get re-invented
just because we don't do a good job of teaching the next generation...

We would love to have you join the community [0]! If you have any
questions/thoughts while learning Go and Pion I will be there to answer them.

[0] [https://pion.ly/slack](https://pion.ly/slack)

------
cozzyd
Sadly pion is not built with meson, a missed opportunity for a particle
physics pun.

------
throwaway9298
Got excited, followed the readme and installed onto VPS. Users can join, but
nothing ever happens beyond the 'waiting for people to join message'.

It seems to bind to a large number of ports (including a port 80 redirector,
which isn't really helpful on a host that's likely to be serving other stuff),
and I can only assume there's some hidden firewall dependency that I've
missed.

Such as shame, as it shows great promise.

~~~
throwaway9298
Turned firewall off, still no dice. Bummer.

------
trog
This looks excellent, nice work and thanks for releasing it at a time when
this kind of thing is even more critical to free us from the shackles of
commercial/closed source products.

I had a quick look only so apologies if I missed it, but are there any
build/deploy instructions that do not require Docker?

Thanks!

------
contravariant
What's the audio latency like? I've been looking for something that can be
made resppnsive enough to allow musicians to collaborate online.

~~~
NortySpock
As I understand it, musicians need latency under 10 ms, which is going to be
tough to get under real world conditions. I'm seeing 12ms round trip to a DNS
server, so you're going to need to be practically in the same building to pull
off a jam session.

[https://www.churchproduction.com/education/latency-and-
its-a...](https://www.churchproduction.com/education/latency-and-its-affect-
on-performers/)

~~~
contravariant
Well, as someone on that pages comments points out, a distance of just a few
meters would give you over 10ms of latency, so I reckon there is some more
leeway.

It's definitely a tricky problem though, which is why I figured a more
customizable solution would be better.

------
cerberusss
Impressive. With mobile SDKs as well.

~~~
Sean-Der
Thanks! cloudwebrtc[0] is on the cutting edge with making Flutter+WebRTC work.
I don't know it as much as I should, but really seems like the future.

[0] [https://github.com/cloudwebrtc/flutter-
webrtc](https://github.com/cloudwebrtc/flutter-webrtc)

~~~
laex
Are there any plans to support react native?

------
ausjke
looks interesting, is this similar to jitsi project as far as functions go?

------
fareesh
What's a good way to estimate server requirements?

~~~
Sean-Der
Sorry I don't have any exact numbers. For fun I threw it on a micro instance
and didn't have a problem with 7 people in the call.

I am going to work on writing an Apache Bench for WebRTC this year though. It
is really hard to load test/bench this stuff because the tooling just doesn't
exist. A lot of people roll out WebRTC, but then go down under real world
load.

~~~
zapttt
for webrtc the load is on the clients. the server load is for "poor
connectivity" clients. the ones tha need nat transversal and proxing of kinds.

in summary, if you have first class clients you can "host" a million person
session in a raspberypi. if you have two bad clients, you better have tons of
cpu and bandwidth!

