Why Videojam Does Not Host Video

Most music platforms describe copyright as a policy problem. Write a notice page. Add a moderation queue. Promise to respond quickly.

That is necessary, but it starts too late. The more important decision is architectural: what does the product take custody of in the first place?

Videojam does not take custody of the media. It stores a YouTube ID and catalog metadata, then plays the video through YouTube's IFrame player. It does not copy the file, transcode it, or serve a replacement stream. YouTube remains the host and the player.

That choice is not a legal footnote attached to the product. It is the rights framework.

1. The embed is the boundary

YouTube's API developer policies permit a compliant API client to display and distribute YouTube audiovisual content through the client. The API terms reserve reproduction and distribution outside the YouTube API Services. That distinction is the line Videojam builds around.

A play on Videojam is still a YouTube play inside a YouTube player. If YouTube monetises the video, Videojam does not replace that system with its own stream. If YouTube restricts playback, the player reports the restriction. If the uploader or a rightsholder removes the video, Videojam has no private copy to fall back to.

This is what I mean by compliant by construction rather than by luck. It is not a claim that an embed makes every possible copyright question disappear. It means the product does not create a second media supply chain whose files, licences, takedowns, and territorial rules it would have to administer.

There is still a curation question. A public YouTube video can be a poor or indefensible choice for a music catalog. That is the subject of our earlier post, An LLM Flagged 1,632 Videos. One Was Real.: the useful signal was who uploaded the video, not what a model guessed from its title. But curation sits on top of the architectural boundary. It does not replace it.

2. Admission is a sequence of refusals

The shared ingest gate asks YouTube for the video's status and metadata. It refuses a missing item, anything not public, and anything whose embeddable flag is not exactly true. For music ingest, it then requires either YouTube category 10 or a YouTube Music topic. It also rejects known promo and filler title classes.

Orientation is checked from the encoded stream dimensions exposed in YouTube's watch page data. If the measured height exceeds the width, the candidate is refused. If that fetch or parse fails, the gate does not pretend it measured a horizontal video. It admits the candidate with aspectUnverified: true, which leaves the uncertainty visible.

There is no universal duration threshold in that shared gate. Some specialist ingest scripts impose their own duration rules, but gateTracks() itself does not. That matters because "we check duration" sounds like one platform rule when the code actually contains several ingest profiles.

The Data API's status.embeddable field is necessary, but it is not proof that the video will play on Videojam. It records the uploader's embed setting. A rightsholder can impose a Content ID block that appears only when the IFrame player runs. In that case the player emits error 151, while the Data API does not expose the block and YouTube's oEmbed endpoint can still answer 200.

So the ingest tooling has a second instrument. It opens the production origin, creates real IFrame players, and classifies their results. A nonplayable candidate is tested again on a fresh page. Only two dead results produce a dead verdict. An inconclusive result is not admitted by the partition helper's default path.

This is less elegant than trusting one API field. It is also closer to the thing a listener will experience.

3. Embeds can die after admission

An embed that works today can fail tomorrow. The uploader can make it private. YouTube can remove it. Embedding can be disabled. A rightsholder can apply a restriction after the catalog entry was accepted.

Videojam does not route around that decision. The player reports YouTube error codes 100, 101, 150, and 151 as dead-video signals. The server then verifies what it can against YouTube rather than trusting a client report that anyone could forge. Network errors and ambiguous responses remain unknown. They do not condemn a video.

When a dead result is confirmed, the catalog records availability: 'unavailable' and an explicit automatic hide. The document is retained so the event is auditable and a corrected source can be substituted later. Public catalog reads exclude unavailable records. A direct shared watch link is the deliberate exception: it resolves to a terminal unavailable state instead of becoming a misleading 404.

There is an awkward edge here. oEmbed can return 200 for the same Content ID restriction that makes the IFrame emit 151. An oEmbed success therefore cannot clear an existing unavailable flag. Restoration belongs to a separate Data API path.

That gap between admission and later failure is worth measuring over time. We intend to publish a link-rot study from it. This is not that study. The point here is narrower: the system treats a rightsholder's later block as an instruction to withdraw the listing, not as an obstacle to evade.

4. The registry mistake that reached nobody

Zero catalog documents carried any of the three wrong channel IDs, so zero users were exposed to the mistake.

We found it during a routine read-only measurement, not because of a complaint or a playback incident. Three entries in the event-channel registry pointed at an abandoned brand channel or a namesake squatter. Because event channels receive a copyright exemption for the sets they publish, a wrong identity in that registry is not clerical. It grants trust to the wrong channel.

Our first fix did not work, and we proved it did not work by testing it.

The first hardened resolver checked whether the returned channel title resembled the expected name. Two of the three bad channels still passed. Of course they did: matching names were how the bad IDs looked plausible in the first place.

The working resolver requires both a title match and an activity floor: at least 50 videos and at least 10,000 subscribers. The test suite refuses all three misidentified IDs and admits every genuine and repaired channel.

Both thresholds matter. One abandoned channel had 30,700 subscribers, enough to clear the subscriber floor by itself, but only 15 videos. The video count was the clause that refused it.

The title comparison also normalises text with Unicode NFD, removes combining marks, lowercases it, and then strips nonalphanumeric characters. That makes a name written with an umlaut comparable with the same name typed without one. It is still only one leg of the decision, not an identity oracle.

The repair is now deployed. The corrected IDs are recorded beside channel titles and activity statistics. The resolver computes resolvedOk from the title check and the activity check together.

This is the useful part of disclosing the mistake. A compliance system is machinery. Machinery can encode a bad assumption. The credible response is not to claim it cannot fail, but to make the assumption testable, watch the first repair fail, and replace it with a discriminator that catches the case.

5. What this gives artists

An artist or publisher does not have to hand Videojam a master file. There is no second upload to maintain and no Videojam copy to retrieve later. The catalog points to the source on YouTube, and playback happens in YouTube's player.

That keeps the practical controls upstream. Availability, Content ID restrictions, and removal remain effective at the player Videojam actually uses. The embed URL also sends Videojam's origin and widget_referrer, so the play is attributable to Videojam in the uploader's YouTube Analytics rather than disappearing into an unlabelled proxy stream.

It also gives artists a direct remedy on Videojam. The copyright and takedown page explains how to identify a listing and contact us. A valid notice removes the listing from Videojam's public surfaces. It does not pretend Videojam can remove the underlying file from YouTube.

The trade is real. Building on an upstream player means accepting upstream decisions, including blocks that reduce the catalog. We choose that constraint. A discovery platform should earn its usefulness by finding and organising work, not by weakening the controls attached to the work.

The embed is not merely how Videojam delivers video. It is how Videojam declines to become the video host, keeps upstream rights controls operative, and makes removal the end of the path rather than the start of a workaround.