Configuring a relay
@@ -431,6 +431,51 @@ looking wrong. With this set, the publishable key stays the +Watching the key log +(relay#("#")32)
+| Variable | +Default | +What it does | +
|---|---|---|
FN_KEY_LOG_SUBJECT_QUERIES |
+on | +Set to false, 0, no or
+off to stop listing a single account's entries. The log
+head and the inclusion proofs still work — only per-subject enumeration
+goes away, and the route then refuses with
+subject_queries_disabled rather than a 404, so a monitor
+can tell "this relay does not answer that" from "there is no log
+here". |
+
GET /e2e/log/subject?subject=<fnid> lists every
+entry published under one account — publications and retirements, with
+the device each names. It is unauthenticated, like the rest of §19: a
+log only its own users can read is not a transparency log, and a monitor
+is by definition somebody else.
⚠️ That has a cost, and it is stated here rather than left to +be discovered. Anyone holding somebody's fnid — the address +they hand to contacts — can see how many devices they have published and +roughly when. This is inherent to key transparency rather than an +oversight: a substitution cannot be detected in a log nobody may read. +What it is not is a directory; you need the identifier first.
+Scripts/watch-key-log.py is a self-hostable monitor,
+forty lines of stdlib. 🔴 Run it somewhere you control — a hosted
+service everybody is enrolled in would learn which accounts are worth
+watching, which is a list nobody should be assembling.
⚠️ It reports what the relay serves. A relay showing +one log to you and another to your contact is the fork §19.4's head +gossip exists to catch, and no single watcher sees it; witness +co-signing (relay#("#")23) is the answer to that and does not exist yet. And +a relay that stops answering is not an all-clear — the script says +"could not reach", never "no changes".