Xinsere × TAMS

Every segment protected. Every timerange permissioned.

The Time-Addressable Media Store (TAMS) turns live and file-based media into the same thing: flows of short segments, each addressed by time. It deliberately leaves security and rights to someone else. Xinsere is that someone else. TAMS keeps the timeline and the query. Xinsere holds, protects and releases the bytes, one segment at a time, only to the parties allowed to have them.

TAMS · the index plane
Flows, timelines, and the query <flow, timerange> → segments. Holds no media.
Xinsere · the media plane
Each segment fragmented, encrypted, scattered. Released only after an on-chain permission check.
Part 1 · How Xinsere works

Defense in depth: security bound to the data, not to a setting

Protected data is broken into sections, each one encrypted with its own key and scattered across hundreds of storage locations. Breach a whole bucket and you recover one encrypted fragment out of hundreds, with no key and no map. Permissions live on a blockchain: immutable, auditable, every grant a block you can read but cannot rewrite. They are bound to the data automatically at publish, so no admin has to wire them up and nobody can quietly widen access.

PROTECTED DATA
Match feed · CAM 1
⛨ Xinsere protected
→
Fragment
split into sections
→
Encrypt
AES-256, a key per fragment
→
Scatter
hundreds of locations
→
Anchor
permissions on-chain
ON-CHAIN PERMISSIONSimmutable · auditable · no admin override bound to the data automatically at publish
grant → Rights holder
0x7a3f…c1
grant → Broadcast partner
0x91b0…4e
verify → Highlights AI
0x2c8d…af
each grant is a block: you can read the history, you cannot rewrite it
Step through fragment → encrypt → scatter → anchor.

Interactive illustration

Part 2 · Applied to TAMS

The camera is a flow. Every segment is a Xinsere object.

TAMS, the open API from BBC R&D, stores media as flows of immutable, time-addressed segments in object storage. Anyone holding the storage credentials can read every segment. With Xinsere underneath, a TAMS Media Object resolves to a Xinsere handle, not a raw storage key. The timeline and query work exactly as the spec describes, and the bytes stay locked until the blockchain says yes.

1 · Query

Ask TAMS for a timerange

<flow_id, [start_end)> returns the segments that overlap. What comes back are Xinsere handles. Nothing is decrypted.

→
2 · Verify

Check the party on-chain

Each segment request is checked against the on-chain permissions for this party. A yes is cached briefly; a no is never cached.

→
3 · Release

Reassemble, verify, play

Fragments are pulled from their scattered locations, decrypted, reassembled and SHA-256-checked bit for bit. If any check fails, nothing is returned.

Try it

One live match, four parties, four different answers

Four flows share one timeline: two cameras, commentary and a stats feed. Pick who is asking, choose a timerange, and play it. Each party gets exactly the streams they hold rights to, segment by segment. Then revoke the partner mid-playback and watch the next request fail.

00:0000:0600:1200:1800:24
Index plane · TAMS query
Run a query to see what comes back.
Media plane · Xinsere gate
Press play. Every segment request goes through the gate.

Interactive illustration The live system runs this same sequence against real segments: real storage, real on-chain checks, real playback. Ask us for a walkthrough.

Why it matters

Live media you can share without giving it away

Share feeds, not copies

Partners, affiliates and vendors query the same store. Nothing is exported, nothing is duplicated, and every segment they pull is permission-checked and logged on-chain.

Revoke takes effect on the next segment

Denials are never cached, so revoking access takes effect on the very next segment request. There is no stale copy sitting in someone's bucket to chase down.

AI agents are just another party

A highlights model or a captioning agent gets exactly the flows and timeranges it is granted, through the same gate, with the same audit trail as a human operator.

A breach yields noise

Segments are scattered as encrypted fragments. Compromising a storage location exposes a fraction of a fraction of a file, with no key and no map.

Standards-shaped

The TAMS timeline, the half-open timerange query and TAI timestamps all work as the spec describes. Xinsere changes where the bytes live and who can get them, not how you address them.

Cloud-agnostic

The protection travels with the object, not the provider. Fragments can live on any cloud or on-prem, next to the compute that needs them.

Where it stands

Running today, and what's next

Running today

  • Real HLS segments ingested through the production Xinsere pipeline: fragmented, encrypted, scattered
  • TAMS-style flows on a shared TAI timeline, with the half-open timerange query
  • Browser playback where every segment passes the gate: verify, reassemble, SHA-256 check
  • Unauthorized parties checked against the live contract and refused, with nothing returned
  • Cryptographic erasure of a whole flow

Next

  • Batched, windowed grants per flow: one on-chain transaction per flow window, not per segment
  • Time-windowed rights: embargoes and "available after" windows enforced on-chain
  • Protection of CMAF init segments as a separate control point
  • Per-flow fragment placement across multiple providers in production

See it run on real segments

We'll walk you through the live system: ingest a feed, query it, play it as an authorized party and as a stranger, and see what comes back.