Repository navigation
Song.link resolution now relies on the HTML scraping fallback #240
Description
Activity
I don't think Musicfetch really fits what we're trying to do with NodeLink.
The Odesli/Songlink issue is valid, but I don't think replacing it with another link-matching service is the direction we'd like to take. NodeLink already handles its sources directly, and we generally prefer keeping the resolution logic under our control instead of relying on another service to handle that part for us.
For this case, I'd rather look into how we can retrieve the same information directly from the supported platforms or handle the extraction ourselves.
So I'd prefer not to add Musicfetch as the default dependency for this.
Hi, I work on Musicfetch and noticed NodeLink’s default Song.link configuration still calls the retired Odesli public API.
Because
apiKeyis blank by default,_fetchSongLinkData()now falls through to scraping__NEXT_DATA__from the Song.link page for every lookup. That leaves resolution dependent on private page structure.amazonmusic.tsalso calls the retired endpoint directly without the same fallback.Musicfetch could provide a supported server-side replacement for both paths. The token could live in NodeLink’s existing source configuration, and platform links are returned under
result.services.I’m happy to test representative NodeLink URLs and sketch the adapter if useful:
https://musicfetch.io/odesli-api-alternative
Dees