New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
QUIC and flutter #10
Comments
Almost forgot this gem !!? go-libp2p-quic-transport |
@gedw99 thanks for sharing this stuff! I know nothing about QUIC, but will do a deep dive this weekend :) |
We don't have to change to QUIC. Am not dogmatic at all about it.
It's more of an option.
Eventually it would be possible to build a webrtc / Quic bridge.
Webrtc is established and has it tricky stuff.
QUIC can be done in 109% golang and so less tricky.
Looking forward to hearing your thoughts...
…On Tue, 19 Jun 2018, 07:31 Sean DuBois, ***@***.***> wrote:
@gedw99 <https://github.com/gedw99> thanks for sharing this stuff! I know
nothing about QUIC, but will do a deep dive this weekend :)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#10 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ATuCwkWdx5yno1L5um7tBTjqff6Kyg-6ks5t-IyXgaJpZM4Uq7dx>
.
|
I am not a QUIC expert, but from my understanding it is not a replacement for WebRTC. There is a proposed protocol to use QUIC with WebRTC, but that's specific to multiplexing QUIC with other types of WebRTC. Rather than replace WebRTC, QUIC would act as the means of transit for certain types of data alongside WebRTC. Abstractly speaking, it seems that something like QUIC could eventually be used for a wholesale replacement for the transport layer in WebRTC, but I think it'd need better primitives for unreliable data. There are some proposals for that, but they are not adopted. Again, I am not deeply knowledgeable of QUIC and it's current direction with respect to WebRTC, but I believe it's not quite right to think of it as a replacement, and too soon to think of it as a full-scale transit layer substitute. I would speculate that it would be interesting to eventually try to integrate the QUIC-extensions proposed to WebRTC for this project, but it may be premature to do so: both QUIC itself and the WebRTC integration for it have not been finalized. |
Google's messaging platform for text and video is 100% based on QUIC. So yes it replaces the transport channel. So if you want video conferencing then you just transcode and stream onto this transport. Am just saying that it can easily replace QUIC and be careful because allot of the opinions are biased due to the webrtc versus Google versus Microsoft war over this standard. I see QUIC as a huge opportuniy to break out of this decades old webrtc legacy code. It's horrible stuff down in the weeds. |
It's going through standards WG at the moment |
https://github.com/libp2p/go-libp2p-quic-transport Probably the best example of the usefulness and practicality of QUIC. You can see the multiplexing aspects in the code and issues |
https://github.com/libp2p/go-libp2p-quic-transport Probably the best example of the usefulness and practicality of QUIC. Unfortunately no example code though. But you can backtrack the to the original author to see examples using cli You can see the multiplexing aspects in the code and issues |
Added to roadmap! I think it would be great if we could play with this in pion-WebRTC. Hopefully we can get to a point where it is easier to prototype things here then other implementations of WebRTC. |
Hey @Sean-Der |
Adding something for the roadmap.
QUIC is a good modern alternative to webrtc that is 100% written in golang.
It what Google used for their Allo video calling app.
https://github.com/lucas-clemente/quic-go
Flutter is a way to build mobile apps GUI.
It has the ability to interoperable between flutter ( dart ) and golang using its platform channels. It's quite easy.
https://www.google.de/url?sa=t&source=web&rct=j&url=https://sites.google.com/a/athaydes.com/renato-athaydes/posts/buildingamobilefrontendforagoapplicationusingflutter&ved=2ahUKEwiv6Jyjq9vbAhVOL1AKHfFoClQQFjAAegQIABAB&usg=AOvVaw3SDogyzDpC13gcMYbgLe0f
So you could use it for P2P data and video !
Just putting here because I reckon it's very doable with all the other bits already in this GitHub org like stun and turn.
Would be happy to team up on this
The text was updated successfully, but these errors were encountered: