/** * Hash-Based Plugin Identification (Phase 2 — Rungs 1 + 1b) * * Identifies installed JARs byte-exactly via the two public hash-lookup * databases that exist for Bukkit-family plugins (research/hash-id.md, * live-validated 2026-06-09): * * - Rung 1 — Modrinth: one batch `POST /v2/version_files` covers the whole * plugins folder (22/74 = 29.7% hit rate measured on the owner's fleet). * Matched `project_id`s are resolved to canonical SLUGS in one * `GET /v2/projects?ids=[...]` call — registry entries and ModrinthSource * identify projects by slug, not id. * - Rung 1b — Hangar: `GET /api/v1/versions/hash/{sha256}` (anonymous, * `view_public_info` scope) for JARs Modrinth missed (+2 unique hits * measured). The endpoint returns the PROJECT only, so the matching * version is pinned with a follow-up versions listing compared against * `downloads[platform].fileInfo.sha256Hash`. * * This is a thin identification utility, NOT an IPluginSource — it answers * "which project is this exact file?", not "what's the latest version?". * A hash hit also corrects lying/unknown installed-version metadata: the * returned version is the byte-exact version of the file on disk. * * Resilience contract: never throws. A failed batch or single lookup logs a * warning and degrades to partial (or empty) evidence — offline returns []. */ import type { ScannedPlugin } from '../types/plugin.js'; import type { IdentificationEvidence } from './identification-types.js'; /** * Identify scanned JARs by full-file hash against Modrinth (sha1, batched) * and Hangar (sha256, per-JAR, only for Modrinth misses). * * Invalid scans (plugin.yml parse failures) are still eligible — hash * identity doesn't depend on plugin.yml. Plugins without computed hashes * are skipped (the scanner owns hash computation). * * Never throws; degraded/offline lookups return partial or empty evidence. */ export declare function identifyByHash(scanned: ScannedPlugin[]): Promise; //# sourceMappingURL=hash-identifier.d.ts.map