

Preface: This is what I learnt about Subsonic and such. The informations below may not be fully correct but the core idea is there.
An API is not a piece of software.
It is merely a way to define how to make a software “do” an action, like search for a song title or download the song file for streaming/playback.
Navidrome does not make use of anything from Subsonic, it merely implements (exposes) a Subsonic-compatible API.
Knowing this information, anyone can run a web request to Navidrome and search for a song, and download/stream it, like they would already do for any other Subsonic-compatible provider:
You can find a plethora of software that can leverage any Subsonic-compatible API provider to connect to that music library, from dedicated Web UIs to Android and iOS apps, which know how to download and stream songs and play them back.
This mechanism gives the user the freedom to choose the backend and frontend, and the developers can just implement the part they prefer: for example, the Navidrome team does not have to build an Android or iOS App, whereas App developers don’t need to write a serverside application to manage the “real” music archive, decode tags, or even implement a search algorithm, as all this data can be asked via the API.
Technically, Navidrome wouldn’t even need a Web UI.
Over the years, the Subsonic API has been forked into OpenSubsonic API, which as far as I could tell, merely serves as a way to better define, and to further add new features into, an otherwise closed and possibly reverse-engineered API.


I would, but in a soft fashion.
However, don’t emulate internet strangers, just be yourself.