Skip to content
Lenstube

Video that outlives the platform hosting it.

Reporting on open video protocols, the storage and delivery stack beneath them, and what creator ownership pays in practice.

Read the journalWhy this address
Concentric aperture rings rendered in indigo on a dark field

The protocols this beat is built on

  • IPFS
  • Ethereum
  • Polygon
  • Chainlink
  • ENS
  • WalletConnect

This domain has a history.

Rather than pretend otherwise, here is the short version of what ran here before, and what runs here now.

  1. 2022

    Lenstube ships

    A video app built on Lens Protocol, with uploads on IPFS and playback through Livepeer. Profiles were NFTs, so the follower graph belonged to the account, not the app.

  2. 2023

    The project becomes Tape

    Same team, wider scope than video alone, new name at tape.xyz. The MIT-licensed code carried over and lenstube.xyz kept pointing at the app for another two years.

  3. 2026

    The domain starts writing

    The app moved on and the address came free. It now covers the field it came from, as a publication rather than a product.

What we cover

Four questions the ownership pitch keeps dodging.

The graph outlives the app

When followers live in a protocol instead of a company database, a client can shut down without taking the audience with it. Lenstube closing and Tape continuing is the clearest proof of that.

Layered signal bars fanning out from a single point

Delivery is the hard part

Storing a file on IPFS is cheap. Transcoding it into every bitrate a phone might ask for is not. That gap is where most open video projects quietly fall over.

Moderation does not disappear

Protocol-level publishing moves moderation to the client layer. Someone still decides what a feed shows, and that decision is worth reporting on.

Creators keep score in payouts

Ownership language is easy. We track the numbers underneath it: what a view actually pays, and how long it takes to arrive.

How the video actually reaches you.

Four hops between a creator's upload and a stranger's screen. Ownership claims live at the first hop. The cost lives in the other three.

Four connected nodes fanning out into a wider signal at the delivery stage
  1. 01

    Upload

    A creator pins the source file. No platform account gates this step, so the same upload works no matter which client reads it later.

  2. 02

    Transcode

    The file is re-encoded into the bitrate ladder a phone or a TV will actually request. This is the compute-heavy step most open projects underestimate.

  3. 03

    Pin

    Encoded renditions are pinned across storage providers so no single host going dark takes the video with it.

  4. 04

    Serve

    A gateway or CDN in front of the storage layer answers the request. This hop is where most of the delivery bill actually lands.

Rented feed, owned graph.

The pitch is always ownership. Here is what actually changes, row by row, between a platform-hosted feed and a protocol-native one.

Platform feed
Protocol-native
Audience
Lives in the platform's database. Gone if the account is suspended.
Lives in a protocol the client merely reads. Portable across apps.
Monetization
Set by a platform algorithm, changed without notice.
Set in the open by whoever pays for a view, visible on-chain.
Moderation
Opaque, enforced at the platform layer, no appeal path.
Enforced at the client layer. Switch clients, keep the graph.
Permanence
Exists as long as the company funding the servers does.
Exists as long as someone, anyone, is paying to pin it.

Latest writing

The first pieces are being written.

Coverage starts with the delivery stack: what it costs to transcode open video, and who is paying for it today.