feat(downloads): add external mod providers

[NoName-txt]

Summary

• add a Download Mod tab with provider selection, filtering, search, sorting, and virtualized infinite grid/list browsing
• integrate RuneForge and DivineSkins catalogs, galleries, video previews, and image fallbacks behind provider-neutral frontend models
• support latest and explicit release installs, including DivineSkins signed download URL resolution and allowlisted image proxying

Verification

• pnpm typecheck
• pnpm lint
• targeted prettier --check for all changed frontend files
• pnpm test (282 passed)
• pnpm build
• cargo fmt --all --check
• cargo test --workspace (482 passed, 5 ignored)

[DexalGT]

Thanks for the PR, but I don't think this is mergeable.

It integrates RuneForge and DivineSkins without permission from either platform, and it goes against their terms of service. I can't speak for RuneForge, but on the DivineSkins side we do not grant permission for this use, and I don't believe RuneForge would allow it either. Crauzer could have built this integration himself at any point over the past years, and the fact that he hasn't is a deliberate choice, not an oversight.

Pulling downloads out of these platforms hurts both the creators and the platforms. Authors chose to publish there under those sites' terms, with their download flow, their attribution, and their takedown process. Routing around that removes the author's visibility into how their work is distributed and removes the platform's ability to enforce its own rules.

[NoName-txt]

Thanks for the PR, but I don't think this is mergeable.

It integrates RuneForge and DivineSkins without permission from either platform, and it goes against their terms of service. I can't speak for RuneForge, but on the DivineSkins side we do not grant permission for this use, and I don't believe RuneForge would allow it either. Crauzer could have built this integration himself at any point over the past years, and the fact that he hasn't is a deliberate choice, not an oversight.

Pulling downloads out of these platforms hurts both the creators and the platforms. Authors chose to publish there under those sites' terms, with their download flow, their attribution, and their takedown process. Routing around that removes the author's visibility into how their work is distributed and removes the platform's ability to enforce its own rules.

Yes, you're right, I was aware of that, but I still wanted to share it to show my support.

It might not be mergeable, but anyone who wants to can use it.

[LadyDarknes]

Instead of resolving and piping downloads through the app, the button could simply open the mods page, in the browser.

[LadyDarknes]

it should work, right?

[Crauzer]

As @DexalGT mentioned, there is a very good reason there is no official integration to both of these platforms. Each one has a different ToS and usage policy. In Runeforge's case there is also no public API which could be utilized for mod browsing. The implementation you proposed doesn't seem to take that into account and just scrapes the site's internal backend endpoint. Even if I were to allow it, the implementation is a smell and a liability at best.

Both platforms prefer offloading mod browsing to their own platform/launcher integration and providing other more relevant features which don't take users off of the platform. I'd also suggest not trying to create forks/clones of LTK Manager with this integration as the platforms reserve their rights to being the sole distributor of mods in the author's name, your implementation would be going against that policy unless manually approved.

LTK Manager does have a plan for providing an official API for integrating external mod platform support if the owners agree. This is what is planned to some degree with Runeforge. Until there are stable/versioned API endpoints, this PR cannot move further in any way.

[NoName-txt]

As @DexalGT mentioned, there is a very good reason there is no official integration to both of these platforms. Each one has a different ToS and usage policy. In Runeforge's case there is also no public API which could be utilized for mod browsing. The implementation you proposed doesn't seem to take that into account and just scrapes the site's internal backend endpoint. Even if I were to allow it, the implementation is a smell and a liability at best.

Both platforms prefer offloading mod browsing to their own platform/launcher integration and providing other more relevant features which don't take users off of the platform. I'd also suggest not trying to create forks/clones of LTK Manager with this integration as the platforms reserve their rights to being the sole distributor of mods in the author's name, your implementation would be going against that policy unless manually approved.

LTK Manager does have a plan for providing an official API for integrating external mod platform support if the owners agree. This is what is planned to some degree with Runeforge. Until there are stable/versioned API endpoints, this PR cannot move further in any way.

Thank you for taking the time to explain your concerns.

I completely understand your reasoning regarding the lack of a public API and the issues with relying on undocumented internal endpoints. My intention was never to violate any platform's ToS or introduce something that could become a maintenance or legal burden for LTK Manager.

The main motivation behind this PR was simply to improve the user experience. I thought it would be convenient for users to browse and manage their mods from a single interface instead of switching between multiple platforms. It was never intended to bypass platform policies or compete with the platforms as distributors, but rather to make mod management more seamless for users.

That said, I respect your decision and understand that this isn't something that can be merged under the current circumstances. If an official, stable API becomes available in the future, I'd be happy to revisit the implementation and contribute in a way that aligns with both the project's goals and the platform's policies.

Thanks again for the detailed feedback.