Kristian WindandClaude Opus 5
78891bae6f
Spørgsmålet er ét: hvor mange bruger det her. Svaret er to værdier én gang i døgnet — et tilfældigt id, installationen selv fandt på, og versionen. Ikke andet. Beskeden er lille nok til at stå i fuld længde på indstillingssiden, og den gør det, fordi et løfte om telemetri er præcis så meget værd som læserens mulighed for at efterprøve det. **Ikke obligatorisk, og grunden er praktisk frem for principiel:** det kan ikke håndhæves. Domænet kan blokeres, binæren kan patches, og en fork fjerner den i første commit — så obligatorisk køber intet over slået-til-som-udgangspunkt og koster den tillid, resten af programmet arbejder for. Hemmeligheder forsegles her, nøglen holdes uden for databasen, og sikkerhedskopisiden advarer om, hvad en kopi indeholder. Telemetri, man ikke må sige nej til, er den ene sætning i den historie, der ikke passer. Uenigheden med `config.UpdateCheck`, som er slået fra med den modsatte begrundelse, står skrevet i pakkens egen dokumentation frem for at blive glattet ud. Den er reel, og læseren fortjener at se begge halvdele. Id'et findes på og gemmes ved første brug frem for at blive udledt af værtsnavn eller adresse. En hash af noget om maskinen ville være stabil, bekvem og samtidig en værdi, modtageren kunne holde op mod et gæt — og det er forskellen mellem anonym og pseudonym. Modtagerens side er den samme binary med en kontakt: `POST /api/v1/beacon` uden login, fordi den, der ringer, er en fremmed installation. Den svarer 404, når instansen ikke er tælleren, så en almindelig installation ikke er en spamspand, der svarer 200 på alt. Ratebegrænset som login-ruterne, og tabellen har et loft: endepunktet indsætter en række på et id, den, der ringer, har fundet på, og uden et loft kunne enhver fylde disken. Tallet er "set inden for tredive dage" og ikke et løbende total. Et total stiger kun og holder op med at betyde "hvor mange bruger det" og begynder at betyde "hvor mange har prøvet det". `internal/safedial` kom til undervejs: modtagerens adresse kan skrives i fladen, og en adresse, en bruger angiver, må ikke kunne pege indad. Kontrollen ligger på den opslåede adresse og ikke på URL'en, fordi et navn kan svare 127.0.0.1 — og svare noget andet anden gang, efter en kontrol ved parsning er gået godt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
27 lines
1.3 KiB
SQL
27 lines
1.3 KiB
SQL
-- One row per installation that has ever reported in.
|
|
--
|
|
-- This table only exists on the instance that is acting as the collector. Every
|
|
-- other instance has it too, empty, because the schema is the same everywhere —
|
|
-- and because "am I the collector" is a setting, not a build.
|
|
--
|
|
-- What is deliberately NOT here is the point of the whole feature: there is no
|
|
-- column for an IP address, a hostname, a domain, an account, a count of tasks,
|
|
-- or anything else. The two things stored are the two things sent, and the table
|
|
-- is the promise written down where it cannot drift from the prose — a column
|
|
-- added here later is a promise broken, and it should be as awkward to add as
|
|
-- possible.
|
|
--
|
|
-- `instance_id` is the primary key rather than a rowid alias, because the same
|
|
-- installation reporting daily must update its row rather than grow a new one.
|
|
-- What is wanted is "how many installations", not "how many pings".
|
|
CREATE TABLE beacon_installs (
|
|
instance_id TEXT PRIMARY KEY,
|
|
version TEXT NOT NULL DEFAULT '',
|
|
first_seen INTEGER NOT NULL,
|
|
last_seen INTEGER NOT NULL
|
|
);
|
|
|
|
-- The count is always "seen in the last N days", so last_seen is what every query
|
|
-- sorts and filters on.
|
|
CREATE INDEX beacon_by_last_seen ON beacon_installs (last_seen DESC);
|