Plugin-request rule update discussion

[bastimeyer]

Let's talk about updating the plugin request/inclusion rules... The last time these rules were updated was in October 2020 and June 2018.

While not being mentioned directly anywhere except in some buried discussions from years ago, there are still plugins on the master branch despite them violating the (current) rules. We never deleted any of those plugins unless they broke and required major changes in order to fix them. Others however were removed with the addition of certain rules.

---

Current plugin request rules

https://github.com/streamlink/streamlink/blob/6.7.2/CONTRIBUTING.md#plugin-requests

1. Any kind of streaming service that uses DRM protection
2. Sites which are hosting stolen content as their main source of content
3. Sites which are primarily rehosting content that is available from a legitimate source (TV shows, sports, news, etc.)
4. Sites which require any sort of cable login or subscription
5. NSFW sites of a pornographic nature (cam sites, porn sites, etc.)
6. Sites which don't provide any real live streaming content, eg. only VODs or VODs being rebroadcasted
7. Sites which don't provide any video streaming content, eg. radio stations
8. Sites where the maintainer has requested we not add their site to Streamlink
9. Sites which are unmaintained, are in beta or are undergoing heavy amounts of development and may change rapidly
10. Sites which have no way to determine viewership numbers
11. Sites which are static cameras of a physical location

Rule "categories"

There are mainly two different kinds of rules, excluding three of the eleven rules:

1. Ones which prevent plugins from being added due to the site's content
   • 1 (DRM content)
   • 2 (stolen content)
   • 3 (rehosted content)
   • 5 (NSFW content)
   • 6 (only VOD content)
2. Ones which were added in order to keep the number of plugins low
   • 7 (no video streams)
   • 10 (unknown number of viewers)
   • 11 (static cameras)

The other three rules are this:

• 4 (cable logins / subscriptions)
• 8 (site asked for the plugin to be removed)
• 9 (unmaintained / in-development sites)

---

Category 1 is pretty much self-explanatory.

Rules of category 2 were added either because of maintenance cost or due to plugins deemed being "not useful" or "too niche" and unnecessarily causing bloat in Streamlink's code base and session memory during runtime. Another reason for adding those rules were people who made daily low-effort requests for sites they didn't even use themselves and probably just found via Google.

Rule change discussions

With the addition of lazy plugin loading in 6.6.0, rules of category 2 could be changed or removed entirely. The only concern would be whether a plugin could be maintained, even if it's "unpopular". This is kind of an important question though, because merging bad plugins doesn't make much sense, and if there's no rule we can point to, then the choice of rejection is arbitrary and always questionable. Ideally we want plugin code to be submitted in a PR instead of plugins to be requested, but allowing plugins of this kind doesn't solve the maintenance issue if nobody is able to fix future issues, even if code is submitted initially. And figuring out which plugins are broken because nobody uses them is also a problem, which means we'd carry around broken plugins for a long time.

Rule 6 may be lifted at some point, but with Streamlink's current VOD support which is pretty bad in terms of viewing and recording, it should stay. The focus is still on live streaming.

No idea about rule 4. AFAICR, this was added because of some sports TV channel requests which required some silly authentication. This rule is not very clear and should be updated or removed.

[gravyboat]

rules of category 2 could be changed or removed entirely.

I don't agree with the removal of category 2 because it will open the flood gates for ridiculous plugin requests again. If people really want those plugins they're free to write them and side load. It's much harder to justify if we don't have an explicit rule for why we don't think the 210th static webcam site of a duck pond should be added for one random person who doesn't even contribute the plugin code.

I'd even argue it would be worth updating the seemingly niche plugins no one uses with a warning message in the console saying that unless they comment on a created issue that the plugin will be removed in the next release.

Rule 6

I don't think we should lift this. Otherwise we'll be spammed with people asking for sites that are "TV" stations that have VODs available of previous broadcasts and TV shows again. These plugins aren't worth maintaining especially since many of them can use the more generic methods for directly accessing the URL of the video if that is what people want.

No idea about rule 4. AFAICR, this was added because of some sports TV channel requests which required some silly authentication. This rule is not very clear and should be updated or removed.

Correct. People were asking for sports TV channels that required login and arguing with us about which rule it broke when no one wanted to do the work for them to add it. I'd be in favor of updating the rule to ban any site which requires login but I know we have a couple plugins like that already and it may be overly harsh. A clarification update would be 👍.

---

Generally I'd be fine with updating the rules for clarity but I don't see a justification for removing any of them. They were all put in place to avoid low effort plugin requests, people arguing with us, seeing the same request over and over (TV VOD sites), etc.

[michaelarnauts]

A lot of the concerns seem to be about people asking for plugins for their favourite site, without having the ability to create them themselves.

Can't there be a rule about not asking for sites, unless you can contribute the code yourself in a PR? Maybe the GitHub discussions could be used for requests instead, so the issue tracker is really used for issues and is kept clean?

[WolfganP]

Regarding streamlink being LIVE streams oriented (rule 6), it may be worthy to communicate it more prominently (ie at the overview section of the documentation, or the readme at the project home landing), and offer a suggestion for VOD site (ie just point the interested user to yt-dlp)
It may also be stressed on the new plugin rules' template by raising it as Rule 1 or so.

Regarding niche sites, wouldn't be a more proactive approach having a catch all plugin like https://github.com/back-to/generic/ ? (no guarantees thou)

[malvinas2]

No idea about rule 4.

Maybe it should depend on how much effort it takes to implement the required login. But generally speaking, if someone makes its paid account available for the duration of development, why not?
Furthermore, it should be taken into account that more and more freely available television channels require some kind of login: BBC, in the future RTVE (according to the announcement on their website), Zattoo Free (widely used), etc.

[soprano1125]

I think of it as "audio streaming = video streaming without pictures".

7 (no video streams)

If we can't merge plug-ins for non-video streaming sites, can't we just have a separate "plugin repository for video-platforms" and a "plugin repository for audio-platforms"?