Doezer/Questarr

Set default path to {platform}/… Add some guidance in the sw Maybe add a "Help" page in the app?

Add localization system, crowdsourced preferably

Use of Jev might be warranted here Problem server/search.ts currently does zero scoring — it aggregates raw Torznab/Newznab results and sorts by pub date only. There's no way to prefer a release group, penalize repacks/DLC-bundles, require a platform match, or reject a wrong sequel/spin-off. Search results are basically unfiltered. What to build A Radarr/Sonarr-style scoring layer, sitting between "search returned raw results" and "show results to user": Title-match classification — distinguish exact match, contains match, and reject ambiguous sequels (e.g. a search for "Dishonored" should not silently accept "Dishonored 2" as a match; a search for "Dishonored 2" should accept "Dishonored 2: Death of the Outsider"). Indexer category classification — decide whether a result is actually a game release vs. something else the indexer returned. Custom formats — user-definable scoring rules matching on title/release-group/uploader/category/protocol, each with a point value. R

Summary notifyUser() in server/socket.ts calls io.emit(type, payload) with no per-connection scoping: export function notifyUser(type: string, payload: any) { if (io) { io.emit(type, payload); } } The connection handler in setupSocketIO() never associates a socket with the authenticated user (no socket.join(userId) or equivalent), so every notification — game availability, download completed/failed, "Release Flagged for Review" AI holds, xREL releases, Steam sync results, etc. — is broadcast to every connected browser tab, regardless of which user it belongs to. Flagged by CodeRabbit (CWE-200, Exposure of Sensitive Information to an Unauthorized Actor) during review of PR #1077, which added a new call site but did not introduce the underlying issue — notifyUser() is already called 20+ times from server/cron.ts alone, and has behaved this way since before that PR. Impact On a multi-user Questarr instance, any authenticated user's browser session receives notifications inte

Follow-up from the CodeRabbit review on #1022 (per-indexer/downloader insecure-LAN credential policy). Two gaps were deliberately left out of that PR as out-of-scope, architecturally larger changes: 1. downloaderAllowsCredentials trusts useSsl, not the resolved request URL server/downloaders/utils.ts's downloaderAllowsCredentials() (and the assertCredentialsAllowed() guard built on it) decides whether a credential may be sent based on the downloader's useSsl config flag. Each client's getBaseUrl()/URL builder, however, keeps an explicit http:// scheme on the downloader's configured url field as-is even when useSsl is true — the two aren't cross-validated. A downloader configured with useSsl: true but a URL field that still literally starts http:// would have downloaderAllowsCredentials return true (trusting the flag) while the actual request goes out over that literal HTTP URL, sending the credential in clear text. Fix: thread the final resolved request URL through to the guard (or v