Local job control
Discordify
Turn a destructive cleanup into a job someone can preview, monitor, stop, and understand before it touches their message history.
- 01INPUTA cleanup scope and filters
- 02SYSTEMA previewable, throttled local job
- 03OUTCOMEVisible progress with a stop control
Repository grounded case study. No staged product demo.
WHY IT EXISTS
The product starts with the problem.
Bulk deletion is not a single button problem. Search scope, filters, rate limits, retries, progress, and cancellation all matter. Discordify makes that operational state visible instead of hiding it inside a script or browser extension.
WHAT IT IS MEANT TO DO
Three jobs, one clear promise.
These are the product outcomes the repository is organized to deliver.
Know the scope first
Users can target one server, direct messages, all servers, every reachable source, or exact message links and IDs.
Preview before deletion
The same search and filtering path can run without deleting so a user can inspect what would match.
Operate the job
Progress, current target, throttling, failures, bounded logs, and an abortable stop request stay visible while work runs.
PRODUCT FLOW
How the idea becomes useful.
A short path from the user’s starting point to a useful result.
- 01
Validate the local session
A user supplied Discord authorization token identifies the account for that local run.
- 02
Choose scope and filters
Date, content, regular expressions, links, files, pinned messages, and exact targets narrow the search.
- 03
Run a preview
Matching messages and target estimates can be inspected before a destructive job begins.
- 04
Monitor or stop
The local job manager tracks requests, waits through rate limits, retries within bounds, and can abort active work.
ENGINEERING IDEA
The choices that define the product.
Architecture matters here because each constraint changes what a user can safely believe or do.
Loopback only server
The Node server binds to 127.0.0.1 so the interface is not presented as a remotely hosted account service.
Explicit job state
Queued, running, stopping, stopped, completed, and failed states make the cleanup lifecycle inspectable.
Small dependency surface
The runtime uses built in Node HTTP, fetch, files, and crypto APIs without production package dependencies.
REPOSITORY PROOF
Evidence, not feature theatre.
Each point below comes from the current repository structure, code, or documented reference data.
Runtime packages
The package manifest declares no production or development dependencies.
Cleanup scopes
Selected sources, all DMs, all servers, every source, and exact targets cover the job model.
Server boundary
The interface is intentionally served only on the local machine.
HONEST BOUNDARIES
What this product is not.
- Discordify requires a Discord authorization token and handles destructive actions against the user’s own messages.
- Discord rate limits apply, and this workflow may conflict with Discord’s rules or change when its private client API changes.
- The project is designed for local operation and should not be exposed as a public hosted service.