Media over QUIC

QUIC API for Peer-to-peer Connections

This document defines a set of ECMAScript APIs in WebIDL to allow data to be sent and received from another browser or device implementing the QUIC protocol. The specification for multiplexing of QUIC with STUN/TURN/ZRTP/DTLS/RTP/RTCP [[RFC9443]] was developed within the IETF AVTCORE Working Group.

Implement QUIC and HTTP/3 in the browser for WebTransport

OpenAI's WebRTC Problem - Media over QUIC

Media over QUIC: There are ways to do voice AI without being traumatized by WebRTC.

Going Peer to Peer with QUIC

Marten Seemann and I just published an entry on his blog, A p2p Vision for QUIC. This is a technical argument, explaining how a series of small improvements to the QUIC standards would suffice to make QUIC a great peer-to-peer (P2P) protocol. I personally love it, because the Internet suffers greatly from excessive centralization, with big platforms acting as gatekeepers. Currently, pretty much all user activities on the Internet are mediated by “services in the cloud”. Take for example something as simple as a security camera in your home. People want to check the camera images when they are outside the home. They cannot connect to the camera or even a home server directly, because the home network is “behind a NAT” – and very possibly behind multiple layers of NAT, given the scarcity of IPv4 addresses. The practical solution is to export the images from the camera to a “service in the cloud”, and to let user contact that service from their cellphone. It works, but it has obvious issues for privacy, security, or even continuity of service: if the cloud service stops, the camera gets bricked. The proposed QUIC architecture would provide a generic solution using the Masque standard for relaying QUIC, combine with QUIC NAT traversal extensions to migrate connections from “using the relay” to “directly P2P”, as shown in the following diagram. +------------------------------+ | Step 1: phone contacts | v the camera through +---|---+ +-----------+-+ the relay | Phone | | Masque ^ | +---|---+ | Relay | | | +-----------|-+ +-------------------------+ | | Step 2: phone and camera cooperate +-----|----|-+ and establish a "hole" in the NAT. | NAT | | | +-----|----|-+ Step 3: traffic flows directly | | between phone and camera without +-|----|-+ burdening the relay | Camera | +--------+ The standards to achieve that are almost ready. The relaying of incoming connections is described in the UDP Listen, already adopted in the Masque Working Group. A draft submitted to the IETF QUIC Working Group describes the Using QUIC to Traverse NAT, and another describes QUIC Address Discovery. I have already implemented the Address Discovery draft in picoquic, and intend to promptly implement the other two drafts. Using QUIC has many advantages. The communications are encrypted end to end, even when they are going through the relay, which has nice security and privacy benefits. The relay is uses standards and is not dependent on the application; if a relay goes out of business, just pick another one. In the weird cases where the NAT traversal fails, the application still works. There are of course many more applications of P2P possible, such as for example direct video calls between two homes, video games and more. The vision is clear: we can do all those applications using QUIC.

streamplace/atmoq-go

Go library for atproto-over-media-over-quic

Quiche Browser — Beautifully customizable web browser

An independent, private, and transparent browser built by a passionate maker. Thoughtfully designed customization options and quality-of-life improvements without sacrificing ease of use. Established browsers can’t compare.

A p2p Vision for QUIC

Using QUIC to achieve everything needed for NAT traversal, from address discovery to proxying UDP

Selkies

Open-Source Low-Latency Accelerated Linux WebRTC HTML5 Remote Desktop Streaming Platform for Self-Hosting, Containers, Kubernetes, or Cloud/HPC

Filling the remaining gap between WebSocket, WebRTC and WebTranspor

Existing web platform facilities for network communication include WebSocket and WebRTC. Each mandates a specific protocol, ensures TLS, and respects the Same Origin Policy. The proposed WebTransport is similar in these respects.

Vidstack Player

A collection UI components and hooks for building media players on the web.

ATOM: AT Protocol Over MoQ Transport

This document specifies how the Authenticated Transfer (AT) Protocol can leverage Media over QUIC Transport (MOQT) for efficient data synchronization across decentralized social networks. The AT Protocol's firehose event stream and repository synchronization mechanisms map naturally to MOQT's publish/subscribe model, enabling scalable relay infrastructure, priority-based delivery, and improved resilience for large-scale social data distribution. This specification addresses the challenges of the current WebSocket- based transport and demonstrates how MOQT's relay architecture, group-based caching, and multiplexed streams provide significant benefits for AT Protocol deployments at scale.

Video Player

A composable, shadcn/ui styled video player component that uses the media-chrome library.

Mediabunny — A complete JavaScript media toolkit for the browser | Mediabunny

A JavaScript library for reading, writing, and converting media files. Directly in the browser, and faster than anybunny else.

Jitsi Meet

Join a WebRTC video conference powered by the Jitsi Videobridge