Does "official clients do not support third party plugins" also rule out a generic capability API?

[halstoproductions]

I want to check a direction before writing anything further, because I may already have my answer.

#4539 asked for Jellyseerr integration and was closed with "Official clients do not support third party plugins." I understand and agree with the reasoning behind that: the client should not carry code for one vendor's product, and that request was specifically for one product.

Before I found that issue I had already built something adjacent, so I would rather ask than assume it is covered.

What I built

A server plugin exposing a request API that is deliberately product-agnostic. The client asks the server what a provider can do, never what it is:

GET /RequestBridge/Capabilities
{ "apiVersion": 1, "canSearch": true, "canRequest": true,
  "supportedStates": ["Requestable", "Requested", "Processing", "Available"] }

The client branches on those flags only. It never learns which product is behind them, and there is no product name anywhere in the client code. A 404 means no provider, and the client shows nothing, so a server without the plugin behaves exactly as it does today. I verified that by removing the plugin and comparing screens.

The plugin is at https://github.com/halstoproductions/jellyfin-plugin-requestbridge (GPL-2.0, 105 tests). A working Android TV implementation exists on a local branch: discovery, requestable items in search results, and status refresh, in about 300 lines.

The question

Is the policy about third party products, in which case a vendor-neutral capability contract might be a different conversation, or is it about anything driven by a plugin, in which case this is equally out of scope and I will stop here?

I am genuinely asking, not relitigating #4539. A clear no is a useful answer and I will take the contract to clients that do want plugin-driven features. I would rather spend one question of your time now than send an unwanted pull request later.

If the answer is "not in this form, but maybe as X", I am happy to hear what X would be.

[nielsvanvelzen]

As you said, we do not support third-party plugins/tools directly from official clients. What we mean by this is that we ONLY support the official Jellyfin API (that is part of the server source code).

At the same time we're well aware that people want to customize various functionalities of Jellyfin. That's why we try to add interfaces to the server that can be implemented by plugins. An example of this is how plugins can supply metadata, lyrics and media segments. And in 12.0 plugins can take over the recommendation and search functions. These kinds of features do not need any client changes.

So for your example, to integrate support with something like Jellyseerr we'd have to create an abstract "media request" API in Jellyfin first which could then be implemented by a jellyseerr plugin.

[halstoproductions]

That answers it, thank you. The rule is about the contract living in the official API, not about the feature being plugin-driven, and a plugin-owned route is exactly what my current design has. Understood.

The shape you describe is the one I would want anyway: the abstraction in the server, a provider plugin behind it, and clients talking only to the official API. IMediaSegmentProvider looks like a close structural match to what a media request provider would need, so there is a precedent to follow rather than a pattern to invent.

I am willing to do that work rather than just propose it. Before writing anything I would rather ask two things than guess:

1. Is a community-contributed abstraction like this something you would want to see as a PR, or should it start as an issue or RFC so the interface can be argued over before code exists?
2. Is new API surface still in scope for 12.0, or is this a later conversation?

One finding that may be relevant to how the abstraction is scoped. I looked at whether IExternalSearchProvider could carry this, since a request affordance mostly matters at the point where a user searches for something the server does not have. It cannot, because SearchResult is a library item id and a requestable item has no id by definition. That is the main thing separating this from the metadata, lyrics and segment providers: those enrich items the server already knows about, and this one has to describe items it does not. It is also why it cannot be done without eventually touching a client, even though the client would only be consuming the official API.

Happy to sketch the interface first if that is more useful than a PR.

[nielsvanvelzen]

Generally with bigger change like that we want a proposal in our jellyfin-meta repository first. When there is a go-ahead from the appropriate teams (in this case, server) you can start on a pull request.