livepeer / livepeer-gateway

Web Gateway To Livepeer's Video Stream Network
MIT License
2 stars 2 forks source link

Persistent URLs #5

Open dob opened 6 years ago

dob commented 6 years ago

The goal is to let a user share a URL in advance of their stream being started, and for that URL to play the stream when it begins. Similarly, if the user stops and restarts their same stream, they should be able to continue at the same URL so they don't have to reshare a new one to their viewers.

This is currently a big weakness of our current "new streamID for every stream" model.

@jozanza has some ideas about an architecture for addressing this by essentially tying the URL to the Eth address of the broadcaster or the job. I think this presents some of it's own challenges, but as a first iteration if we could use a persistent URL, it would make "eating our own dogfood" a lot easier.

dob commented 6 years ago

One other idea that I had was just to back a "persistent stream URL" with a smart contract registry. This would be a mini dapp that would...

  1. Let a user register a URL.
  2. Let that user update the streamID currently available at that URL.
  3. Maybe even include metadata about the stream like the time that it was supposed to start, and the IPFS hash of the recording of the stream after it ended.

This may be a separate DApp or separate issue, but in some ways I could see this path being easier than trying to shoehorn persistent URLs into our current streamID/job/broadcaster address in a way that creates an actually usable experience.

jozanza commented 6 years ago

Right now, the new player supports urls with the broadcaster address, streamId, or "channel id" -- base58 of a jobId -- to allow for shorter/more shareable urls.

Meta information shown inline currently includes

An additional persistence layer (maybe more non-protocol smart contracts) would be ideal for adding more meta information. Also, working out various methods of content discovery via the networking protocol would be really awesome.