One video has seven numbers here: 43% of cases carry more than one identity

By Alpha Lay · 2026-09-26

We previously wrote about one video being saved by two hosts (27.5% mirror duplication). Auditing the fields turned up a second layer of duplication: the same video numbered separately by different indexing projects.

Where the data comes from

Each case has an ids field recording the identifiers that video carries across sources. Every ID has a namespace prefix, e.g. sns-x-2082563241062875568 (derived from an X post) or beatapi-5-4-3-3a-cg-1.

Finding 1: 43% of cases have more than one identity

550 records (43.2%) carry two or more IDs.

One extreme example:

One video, three numbers, two namespaces. Note the last two are even from the same project — not even a single project keeps one ID per video.

Finding 2: At least 8 indexing projects numbering independently

Eleven namespaces. What is sns? It is our own convention: an ID derived directly from the X post ID (sns = social network service). Meaning only that one line is ours; the rest were assigned by others.

That has a practical consequence: if a video only ever appeared elsewhere and we have no post link, we can only inherit someone else's ID. If that ID dies (the other site goes offline), the record loses its unique anchor.

Finding 3: File-level duplication, by contrast, is rare

An interesting contrast:

Identities duplicate 12.8x more often than files.

An earlier piece noted 350 records are cross-host mirror duplicates — that was counted by "original publication link." Here, counted by "file URL," only 43. The two numbers are not in conflict; together they say:

• The same file is almost never re-listed (whoever lists it swaps the URL)
• The same video is almost always re-numbered (every project names it anew)

So: in this space, identity cannot be determined by file or by ID — only by the original publication link. That is why we settled on src as the dedup key.

What you can do with this

If you merge multiple AI video case sources: do not match on ID and do not match on file URL. By the data, those are single-valued for only 57% and 97% of records respectively — whereas the original publication link connects across projects.

If you run an indexing project: note the apimodels example — even inside one project, a trailing hash was needed to disambiguate (…-bb74d608). Merging multiple sources in practice produces "same thing, different number," so define your ID derivation rule up front (like our sns-x-<postID>, derived from the platform ID, which aligns across projects by construction).

If you publish content: to get your case merged correctly, keeping one stable, addressable link to the original post matters more than anything. URLs change, IDs get reassigned; the original post is the only anchor.

Method and limitations

• ids is a field we assembled, and we may not know every identity a video has. So 550 is a lower bound — the true multi-identity rate is higher.
• Namespace prefixes are inferred from ID strings, not confirmed by the projects themselves. Two naming conventions from one project may appear as two namespaces here.
• We do not claim "8 projects" equals "8 independent organisations": several may be product lines of one party.
• No claim about who copied whom: this reports "one video has several numbers" and does not address citation relationships or licensing between projects.
• All figures use the 1,274 index records.

Reproduce it

Case detail views carry all known IDs: https://cases.aishifu.shop/