Hey SN,
Putting up an MVP I've been working on. Satstreamr is metered peer-to-peer video. The viewer connects to the streamer over WebRTC and pays in Cashu micropayments, sent over the same data channel that carries video metadata.
How it works
Every 10s or so the viewer's browser sends a Cashu token to the streamer. The streamer redeems it with the mint and sends back an ack. If no ack comes, the stream pauses. If the wallet runs empty, the session ends.
Lightning only shows up at the edges: viewer funds via LN deposit, streamer cashes out via LN withdrawal. The per-interval loop never touches LN.
Why Cashu mid-session instead of Lightning
A Lightning payment per tick means hundreds of ms of variable latency, plus routing failure risk. A Cashu swap is one HTTP round-trip to the mint. Latency might end up similar, but it's predictable and there's no routing. The tradeoff is you trust the mint while the session runs.
One detail worth mentioning: the viewer pre-splits proofs into exact-denomination chunks before the session starts, so each tick is just "pick one, send it".
Repo: https://github.com/bilthon/satstreamr
Live version: satstreamr.com
Limitations
- 1 viewer per session (signaling is 1:1 by design right now)
- No auth, the session ID is the only gate
- Both sides have to use the same mint
- No recording
Feedback I'd love
- Does the trust model (mint custody during the session, same mint on both sides) feel workable? Where does it break?
- Anything obviously naive in the payment loop or the pre-split design?
- Would you actually use this, and for what?
There are a few commercial directions this could go, but I'm not chasing them yet. I'd rather hear what people think of the underlying piece first.
Happy to get into internals in the comments.
The pre-split approach is great, having exact denomination chunks ready so each tick is just grab and send keeps the latency predictable. The mint trust during the session seems fine for something like video where the worst case is you lose a few seconds of stream. I'm curious if you've thought about what happens when you scale past 1 viewer though, does the payment loop stay simple or does it need some kind of relay or something else?
Thanks for the reply, interesting points! I think to scale past the current 1-to-1 architecture I'd need to set up a video streaming server. The payments can still remain something peers exchange directly.
Does the receiver or the sender determine the mint?
Also the fact that lightning isn't used directly sucks.
Right now the mint is hard-coded. I wanted to get it out there as fast as possible, so certain features had to wait. The next thing I plan to add is support for users to chose their mint from a list of curated ones.
It seems pretty cool to me. I don't mind the same mint being used on both sides. I'm not sure what stream would be high stakes enough to cause this to be a concern.
As far as actually using it, probably not. But I don't currently use any streaming service.