[API Request] Explicit server name and version

[Tolriq]

Type of change

API tweak

Proposal description

Since not all servers support the same subset of features and may have small differences in their actions, it’s important for clients to be able to identify the server type to be able to adapt.

Purpose: Expose server name and version in subsonic response.

Note: Currently there’s different implementation by some servers.

The proposal is based on current Navidrome implementation.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

Expand the subsonic-response with new fields

type : String - The server type (“Navidrome” / “Ampache” / “Gonic” / …)
serverVersion : String - The server version (“X.Y.Z” …)

Security impacts

By disclosing the server name and version it can help hackers to better target known vulnerabilities if they exist. (But in all case since being a Subsonic server is exposed they usually run their whole set of tests)

Potential issues

No response

Alternative solutions

No response

[Tolriq]

Server implementation status

Navidrome: OK
Ampache [>5.5.8]: OK
Gonic: type is set but no version is exposed
Funkwhale: type is set but version is exposed as funkwhaleVersion
Astiga: exposed Astiga/production in serverVersion
Lms: type is set but no version is exposed

[gravelld]

Astiga: expose Astiga/production in serverVersion

This should be done...

[Tolriq]

Well yes this is the list of current status.

But if we were to validate this in the current form, then it would be nice to rename the field to match the documented extension.

[gravelld]

Ok, I changed expose to exposed then...

[sentriz]

added type and serverVersion to gonic 👍

has the openSubsonicVersions key been fully decided on yet? don't see it in the "In production" tag on discussions

[Tolriq]

Yes it's now validated and in prod will change the tag. (And documented https://opensubsonic.netlify.app/)
Edit: Actually discussion have restarted see the Issue and opened PR #30

[spl0k]

I see the OpenSubsonic server support section on the subsonic-response page. I guess it's just a matter of time before everyone updates, but shouldn't we remove this section, at least for now? It's clearly showing that some participants don't comply to the standard they're trying to build.
Come to think of it, I would just remove it and never add it again, same for all the other pages it appears. It requires to follow how servers implement this or that endpoint/extension/etc and will obviously be out of date at some point. Plus new servers might want to be added there, increasing the maintenance need for something that, in my opinion, doesn't bring anything useful for this documentation as a whole.

[Tolriq]

This is a little complicated

1. I do hope that having this will have 2 side effects. Motivate some servers to implement the basic thing (so nearly no work) to comply fast to kick start this. And motivate more other servers to be visible here. At some point only the https://opensubsonic.netlify.app/docs/ participant page will be enough to achieve that. So the supported servers on the mandatory end points will not be necessary.
2. Since all the extensions are optional, I think that it's important for clients to be able to know what servers do implement the extensions. Again for 2 purpose. The first one is basic testing, it's easier to have a working server to test a feature. The second is again the same snow ball effect. If a client sees that most servers do support an end point then it will motivate to implement, and on the other side when more clients supports an endpoint it will motivate servers to implements seeing it's used.

So yes right now at the start (for what I hope will be less than a couple of month) you might think it's a shame wall, but it's in fact the opposite a push toward being better wall. Leading to a needed data later that will also serve as a trampoline for the success of this project.

There's month of work on my side to try to bring this to life and work with people and motivate people to get the type and search3 end point as the starter to this project. There's still some servers not supporting those 2 basic things.