This is still just streaming a static file though. Adjusting which segment to get will work, buffering will work, and people don't mind their movie starting a few seconds after they press play.
If I'm streaming live, I need the frame immediately, and it doesn't help much to get later frames after the frame I'm missing.
Live streaming is, by nature, a "one-to-many" distribution model, where content flows from a single source to many viewers in real time.
BT, on the other hand, is fundamentally designed for "many-to-many" distribution, where peers share pieces of content with each other over time. This isn't just a question of tweaking the protocol—it's a fundamentally different problem. Unless you're willing to compromise on the immediacy of the stream, using BT for true live streaming isn't really a good fit.
what if everyone agrees on a 10s delay?
For pseudo-live streams such as sports events, that would be totally fine. People can have slightly out of sync streams, delayed by various amounts.
But you can't live stream a conversation with someone if you have a 10s delay.
Latency is actually a pretty big deal for live sports events.
No one wants to hear the cheering start at the neighbor's house ten seconds before you get to see the team score a goal.
And yet, that is exactly what we have!
The issue is everyone is watching the same part of the file at the same time. Offsetting by 10 seconds does not change that.
The time offset impedes the ability of viewers to interact with the streamer via chat, which for many people (incl. myself) is the whole reason to watch live instead of a recording.
Define "live".