Stream Key Support

[dob]

This is a discussion issue to suggest the idea of adding support for stream keys to LPMS. The need for this comes up constantly as we discuss the various use cases for how people will use Livepeer - self hosting ingest servers on the open internet, that require authentication in order to actually push a stream.

Perhaps the API is something like

generateStreamKey(expiration_date)

revokeStreamKey(key)

And a flag on startup --authenticationRequired, which would indicate that to accept an RTMP stream a streamKey must be provided?

Perhaps the currently valid stream keys are stored in a config file, such that if you're running multiple nodes you can easily create a process which updates the valid stream keys across machines?

Clearly this deserves more design and discussion - but it seems like a valuable feature of any open source media server.

[j0sh]

Agreed. When considered alongside livepeer/go-livepeer#429 and livepeer/go-livepeer#481 , the idea of stream keys plays well with the idea of 'stream aliases' which points a fixed (possibly random) name to an underlying job that may change. The underlying job may change for various reasons, eg the job expires, the user finds a better/cheaper transcoder, transcoding preferences get reset, etc. This would greatly improve the UX with capture tools such as OBS (no need to reset the key each time the job changes), while enhancing security and utility in public or multi-tenant environments.

There's a few ways we can do this:

1. By setting a secret key as part of the stream path, Twitch-style.

With a separate job creation step, we can create the key/alias alongside the job. This could optionally be random, giving us a secret "stream key". Along with that, we can supply options to revoke an alias, create aliases separately from a job (eg, multiple aliases per job? Might allow for a deeper level of job reuse along with livepeer/LIPs#14, given a way to optionally propagate a broadcaster stream name), and so forth.

An --authenticationRequired (or equivalently, --aliasOnly) flag would absolutely be needed here if we allow the stream to be addressable by some other easily guessable method, eg JobId or an on-by-default stream/latest feature to reuse the latest job.

2. Using traditional username:password RTMP auth.

Already well supported by OBS, ffmpeg, etc. However, this doesn't give us a quite as clean a method of 'stream switching' unless it's indexed solely by the username:password.

[j0sh]

With RTMP authentication webhooks we effectively can build stream keys on top of LPMS now, so we can close this issue.