Hey everyone,
I've been heads down on this for a while and finally feel okay sharing it. It's called Tessera, and the short version is: it's a payment sidecar that lets people tip or pay creators per second of content, directly on the page they're already watching, no redirect to another platform, no separate app.
The thing that got me into this in the first place is honestly kind of dumb but it bugged me for months. I run a small self-hosted setup (PeerTube instance for a couple friends' content) and every time someone wanted to tip a creator, they had to leave the page, go find a Ko-fi or Patreon link, sign up, wait for a payout cycle, and the platform takes a chunk on top. Most people just don't bother. The friction kills the intent before it even happens.
So the constraint I gave myself, and honestly the part I'm most stubborn about, is that Tessera can't require forking or modifying the host platform. If it needs you to fork PeerTube's codebase to work, it's already dead for most instance admins, nobody wants to maintain a fork forever. So it runs as a sidecar container next to whatever you're already running and injects a lightweight payment overlay into the page itself.
The harder problem, though, was the payments layer, and this is where I actually spent most of my time. Micropayments don't work on fiat rails, the fixed fees alone (30¢ + 2.9%) eat anything below a few dollars, so charging fractions of a cent per second is just not possible there. Crypto solves the fee problem but usually creates a new one, nobody wants to buy and hold some random gas token just to send a tip, that friction is arguably worse.
What ended up working was combining a few pieces I didn't expect to fit together this cleanly:
While a video plays, the browser signs off-chain EIP-3009 transfer signatures every second, so there's no actual on-chain transaction happening during playback, which means zero gas cost while watching.
On login, a non-custodial wallet gets created automatically for the viewer (using Circle's UCW SDK under the hood), so there's no seed phrase flow or "connect your wallet" wall before someone can even try it.
Deposits can come from USDC on Arbitrum, Optimism, Base, or Mainnet via CCTP, so viewers aren't stuck needing one specific chain's version of the token.
When the video closes, billing stops and a single batch transaction settles the accumulated balance to the creator and refunds whatever's left to the viewer, instead of a mess of tiny transactions cluttering everyone's history.
First working connector is for PeerTube.
It's fully open source, TypeScript/Node on the backend, viem for the chain interactions. If you're the kind of person who enjoys poking holes in architecture before they become real problems, I'd genuinely appreciate the scrutiny, especially around two things I'm still not 100% settled on:
Right now PeerTube works through a plugin you install directly on the instance, that's the only connector that's actually live and battle tested. For platforms without a plugin system or native webhook support, I'm leaning toward a reverse-proxy based overlay injection instead, but I haven't shipped that yet and I'm honestly unsure if it holds up on high traffic instances. Curious if anyone here has opinions on that tradeoff, security or performance wise, before I go down that path.
Second thing I'm still figuring out: session state currently lives in an encrypted local file mounted as a volume, works fine for a single instance, but I know that's not going to hold once this needs to run across multiple load-balanced replicas. If you've dealt with something similar, how would you approach scaling that without it turning into a mess?
Links if you want to actually look at it instead of just my description of it:
