Listening Parties

Listening Parties

A listening party is synchronized playback across several people, each running their own copy of Orchard.

How it works

Parties are peer-to-peer. Orchard's listening-party Cloudflare Worker handles room coordination and WebRTC signaling only; it never proxies or streams audio. Every participant plays the audio locally from their own YouTube Music session.

That has two consequences worth knowing:

• Everyone needs their own working Orchard playback. The host is not streaming to anyone.
• Nothing about the audio passes through Orchard's infrastructure.

Roles

The host controls playback and the queue. Host actions broadcast to everyone.

Guests follow along and can send requests to the host to play, pause, seek, or queue something. The host decides whether to act on them.

The host can transfer host status to another participant, and can close the room.

Starting and joining

Start a party from the player. Orchard creates a room and gives you an invite to share. Joining uses that invite. Room metadata is public to anyone holding the room id, and each participant gets a token scoped to that room.

Protocol

The worker exposes:

Endpoint	Purpose
GET /health	Liveness
POST /rooms	Create a room, returns a host participant token
GET /rooms/:roomId	Public room metadata
POST /rooms/:roomId/join	Create a guest participant token
GET /rooms/:roomId/socket	Upgrade to the room WebSocket

Over the socket, clients send signal to relay WebRTC offer, answer, and ICE payloads; the host sends party:update to broadcast synced playback state, party:host-transfer, and party:close; guests send party:request; and party:ping keeps connections alive.

Rooms are backed by a Durable Object, which is what makes a single authoritative room state possible at the edge.

Sync accuracy

Sync is state-based rather than stream-based: the host broadcasts what it is playing and where it is, and each client seeks to match. Small drift between participants is normal, particularly across very different network conditions. Skips and seeks resynchronize everyone.

Limitations

• All participants need access to the track. Regional availability differs by account, so a track playable for the host may not be playable for a guest.
• A guest without a signed-in session may be unable to play age-restricted content the host can play.
• Closing the host's Orchard ends the room unless the host has transferred the role first.

Related

• Orchard Connect is for your own devices on a LAN, which is a different problem from a party across the internet.
• Cloudflare Workers covers deploying your own signaling worker.

Source map

Path	Role
src/app/social/listeningPartyActions.js	Party lifecycle in the renderer
src/app/social/listeningPartyClient.js	Socket and WebRTC client
workers/listening-party/	Room coordination and signaling worker