I Built a YouTube Watch-Together Extension in a Day

Rocky Singh — Sun, 05 Apr 2026 16:19:03 +0000

TL;DR: My friend and I wanted to watch YouTube together from different cities. Every existing solution required a separate website or screen sharing. So I built a Chrome extension that syncs playback with a toggle. Supabase Realtime, zero backend, one afternoon, under 1,200 lines of TypeScript.

You and a friend are in different cities. You want to watch the same YouTube video at the same time. Pause when they pause, seek when they seek, switch videos together. There are services for this, but they all require opening a separate website, pasting links, or screen-sharing through a call.

What if you just... toggled a switch next to your friend's name, and your browsers synced?

That is what YPlay does. A Chrome extension backed by Supabase Realtime, built entirely in one sitting. Under 1,200 lines of TypeScript, one external dependency beyond React, and zero backend infrastructure beyond a free Supabase project.

The Problem With "Just Watch Together"

Every watch-together tool I tried had the same friction: leave YouTube, open some third-party site, create a room, share a link, hope everyone joins before the video starts. By the time you are "synced," the spontaneity is dead.

I wanted something that lived inside YouTube. No context switching. No room codes to copy-paste. Just open YouTube, toggle a friend on, and you are watching together. That meant building a Chrome extension.

OAuth in an Extension Is Weird

Extensions cannot use normal browser redirects for OAuth. There is no URL bar, no page navigation. Chrome provides chrome.identity.launchWebAuthFlow, which opens a controlled popup for the OAuth dance and returns the final URL with tokens.

The trick is telling Supabase not to redirect the browser, because inside an extension popup, there is nowhere to redirect to:

const { data } = await supabase.auth.signInWithOAuth({
  provider: 'google',
  options: {
    redirectTo: chrome.identity.getRedirectURL(),
    skipBrowserRedirect: true,
  },
})

const responseUrl = await chrome.identity.launchWebAuthFlow({
  url: data.url,
  interactive: true,
})

Sessions get persisted to chrome.storage.local instead of localStorage, because the popup's DOM is destroyed every time you close it. Forget this and your users log in fresh every single time they click the extension icon.

From Room Codes to Friend Toggles

The first version had a room code input. Type a six-character code to join. It worked, and it was terrible UX. Nobody wants to coordinate codes over text just to watch a video.

So I replaced it with a friend system. Send a friend request by email. Accept it. Then toggle a switch next to their name. Done.

The room code still exists under the hood, deterministically generated from both email addresses:

function generateRoomCode(email1: string, email2: string): string {
  const sorted = [email1.toLowerCase(), email2.toLowerCase()].sort()
  const str = sorted.join(':')
  let hash = 0
  for (let i = 0; i < str.length; i++) {
    hash = ((hash << 5) - hash + str.charCodeAt(i)) | 0
  }
  return Math.abs(hash).toString(36).toUpperCase().padEnd(6, '0').substring(0, 6)
}

Same two people always get the same room. No server coordination. No "who creates the room?" problem. Toggle on, you are connected.

Friend requests are email-based deliberately. You can invite someone who has not signed up yet. When they eventually install the extension and log in, the request is waiting.

The Sync Engine

The background service worker subscribes to a Supabase Realtime broadcast channel for the active room. Six events handle everything:

Event	What It Does
`sync-video`	Navigate to a new video URL
`sync-play`	Resume playback
`sync-pause`	Pause playback
`sync-seek`	Jump to a specific timestamp
`open-youtube`	Open YouTube if not already open
`youtube-status`	Report whether YouTube is active

Every event carries a machine_id, a stable UUID per browser. This is how the extension ignores its own broadcasts. Without it, pausing your video would broadcast a pause, which would come back to you, which would... you get the idea.

No custom WebSocket server. No signaling infrastructure. Supabase Realtime handles all of it. The entire "backend" is a Supabase project with two tables and some RLS policies.

The Hardest Problem: Echo Suppression

Here is the thing nobody warns you about when building real-time sync: every action causes a reaction that looks like a new action.

When the remote peer says "pause," the content script calls video.pause(). That fires the native pause event. The content script is listening for pause events to broadcast them. So it broadcasts a sync-pause back to the room. The other person's video pauses again. Infinite loop.

The fix is a set of suppression flags:

let suppressPause = false

// Remote command arrives:
if (msg.type === 'pause-video') {
  suppressPause = true
  video.pause()
  setTimeout(() => { suppressPause = false }, 500)
}

// Local event fires:
function onPause() {
  if (suppressPause) return  // swallow the echo
  chrome.runtime.sendMessage({ type: 'video-paused', videoId: vid })
}

Same pattern for play, seek, and video navigation. Each has its own flag. Each flag auto-disarms after 500ms. It is not elegant, but it is dead reliable.

Video-level echoes need a separate mechanism. When a sync-video navigates to a new URL, the content script reports that URL as a local navigation. The background stores the last synced video ID and swallows the duplicate. Seek events get debounced at 300ms because YouTube fires multiple seeked events from a single click on the progress bar.

The Multi-Tab Problem

What happens when you have three YouTube tabs open?

Without handling this, every sync command goes to a random tab. Or worse, all three simultaneously. The solution is a tab-selector overlay: a full-screen dark modal injected into every YouTube tab asking "Use this tab for synced playback?"

The background maintains the selected tab ID and routes all operations through it:

async function withSelectedTab(callback: (tabId: number) => void) {
  const selectedTabId = await getSelectedTab()
  if (selectedTabId !== null) {
    callback(selectedTabId)
    return
  }

  const tabs = await chrome.tabs.query({ url: '*://*.youtube.com/*' })
  if (tabs.length === 1 && tabs[0].id !== undefined) {
    await setSelectedTab(tabs[0].id)
    callback(tabs[0].id)
    return
  }

  pendingCallbacks.push(callback)
  showTabSelectorOverlays()
}

One tab? Auto-selected. Multiple tabs? You pick. Selected tab closed? Selection clears and auto-resolves if only one remains. Commands that arrive before a tab is selected get queued and execute once you choose.

Keeping Manifest V3 Service Workers Alive

Manifest V3 killed persistent background pages. Service workers get terminated after ~30 seconds of inactivity. A dead service worker means a dead Realtime connection. Your friend pauses their video and nothing happens on your end.

The fix is a chrome.alarms heartbeat:

chrome.alarms.create('yplay-keepalive', { periodInMinutes: 0.4 })

chrome.alarms.onAlarm.addListener((alarm) => {
  if (alarm.name === 'yplay-keepalive') {
    ensureConnected()
    broadcastYouTubeStatus()
  }
})

Every 24 seconds, the alarm fires. If the channel dropped (it will), ensureConnected() re-subscribes. These are the most important four lines in the entire extension. Without them, sync silently dies after half a minute of inactivity.

Note:
Chrome clamps periodInMinutes to a minimum of 1 minute for published extensions. The 0.4-minute interval only works during local development with unpacked extensions. In production, this alarm fires every 60 seconds instead of 24. That is still fine, chrome.alarms wakes the service worker even if it was already terminated, so ensureConnected() re-subscribes and sync resumes within a minute at worst.

Design Decisions That Mattered

Email-based friend requests. You can invite people before they sign up. The request is waiting when they arrive. Zero coordination overhead.

Deterministic room codes. No "who creates the room" negotiation. Same two emails always produce the same room. Toggle on, you are in.

Auto-accept mode. A small toggle that lets your friend join your session without you confirming. For close friends who watch together regularly, this removes the last point of friction.

Graceful tab handling. If a sync event arrives and no YouTube tab is open, the extension opens one automatically with the right video. No silent failures.

What I Would Do Differently

Polling for invites. The friends panel polls every 5 seconds for new invites. Supabase Realtime's Postgres Changes feature could push them instantly. The background already has a Realtime connection. It could listen for INSERT events on room_invites.

The room code hash. Six characters from a truncated hash works for 1:1 watching. Group sessions (3+ people) would need a different mechanism, and the collision risk is non-zero.

Seek threshold. Seeks under 2 seconds are silently ignored to avoid noise. For music videos where timing matters, this could be noticeable.

What I Learned Building This

Start with the interaction, not the infrastructure. This did not begin with "let me set up a WebSocket server." It began with "what if I just toggled a switch?" The simplest UX drove every technical decision.

Supabase Realtime is underrated for extensions. Broadcast channels give you pub/sub without managing connections. Combined with chrome.alarms for keep-alive, it is a complete real-time backbone for zero infrastructure cost.

Echo suppression is the real problem. Sync itself is easy. Broadcast an event, execute it remotely. The hard part is making sure remote executions do not trigger new broadcasts. Every real-time sync system eventually reinvents this wheel.

Chrome extensions have sharp edges. OAuth without redirects. Sessions without localStorage. Background scripts that die after 30 seconds. Each one is a blog post waiting to happen, and each one has exactly one right answer buried in the docs.

The Takeaway

Every developer has a "why doesn't this exist?" moment. Usually it is followed by finding out it does exist, just not the way you want. YPlay started because I wanted to watch YouTube with a friend without leaving YouTube. The technical stack (Supabase, Manifest V3, content scripts) all followed from that one constraint.

Sometimes the best architecture is the one you can build before dinner.

DEV Community: Rocky Singh