Content signing & origins

Peer delivery introduces a trust problem: if a viewer accepts segment bytes from another viewer, how does it know those bytes are the real segment and not something a malicious peer swapped in? MeshedFlow answers this with origin-signed segment manifests. A peer can hand you bytes, but it can’t make you accept bytes that don’t match what your origin signed.

Why signing exists

The mesh is only safe if a peer can never feed you tampered media. Every segment a peer delivers is checked, byte for byte, against a manifest that was signed by MeshedFlow’s control plane using a key only the control plane holds. If the bytes don’t match the signed manifest, the segment is rejected and the request falls back to your CDN. Only verified media is ever handed to the player.

How it works

1. The control plane holds the signing key. MeshedFlow’s control plane holds an ECDSA P-256 private key. It is the only signer — the key never leaves the control plane.

2. Signing re-fetches from your origin. When a manifest is signed, the control plane fetches the segment directly from your origin, recomputes its SHA-256 checksums, and only signs a manifest that matches the real origin bytes. A client can’t get a signature for content the origin never served.

3. The SDK auto-fetches the public key. On startup the SDK fetches the published verification key (a JWK, ECDSA P-256 / SHA-256) from the signaling host and uses it to verify every peer-delivered segment. This is controlled by two options, both on by default:

   • autoFetchManifestPublicKey (default true) — fetch the public key automatically. You don’t ship the key yourself.
   • requireManifestSignature (default true) — require a valid signature before accepting a peer segment.

4. Every peer segment is verified. Before a peer-delivered segment reaches the player, the SDK checks its bytes against the signed manifest. A mismatch is rejected and the segment is fetched from the CDN instead.

Tip

You don’t call any of this. With the three required options set, the key fetch and per-segment verification happen automatically inside the SDK.

The content-origin allowlist gate

Signing is scoped per tenant by a content-origin allowlist. When the control plane is asked to sign a segment manifest, it looks up the effective allowlist for the caller’s customerId and refuses to sign any URL that isn’t on it.

An origin matches when:

• the scheme and host match (compared case-insensitively — https + cdn.example.com), and
• if the allowlist entry includes a path prefix, the segment URL’s path starts with it. An entry with no path (or just /) matches any path on that host.

The effective list is per tenant: the control plane uses your tenant’s own allowlist when you’ve set one, and falls back to the platform’s global env allowlist otherwise. If the effective allowlist is empty, every sign request returns 403 — nothing can be verified, so nothing offloads.

An empty or wrong allowlist means 0% offload

This is the number-one reason a correct-looking integration shows 0% offload: the segment origin isn’t in the allowlist, so signing returns 403, no segment verifies, and everything falls back to the CDN. Add your origin in the portal first — see the API origins endpoints and Troubleshooting.

Managing your origins

You manage the allowlist from the portal, or via the HTTP API:

• GET /control/tenants/:id/origins — read your current allowlist.
• PUT /control/tenants/:id/origins — replace it.

Both accept your tenant id or your customerId in :id, and a tenant-role session may manage only its own list. Origins must be valid http/https URLs with a host. An empty list clears your tenant’s allowlist and falls back to the platform default. See the HTTP API reference.

Related

• Authentication & provisioning — where your customerId and token come from (the token’s customerId selects the allowlist).
• Core concepts — how verification fits into the delivery decision and CDN fallback.