jcoffey-dev is traveling from Thursday 1 October through Sunday 4 October. Issues and pull requests are welcome, and will get an answer after that. Thanks for your patience.
New installs only (no roles yet): ban periods 30 d (D2), spam samples 90 d (D3), Pyzor off (D4), traces 14 d (D6). Each singleton is read, changed, written back whole.
D7: new webhooks default to include with no events (Rust + schema default). Stored webhooks keep theirs.
Daily clean-up removes expired bans.
D1 and D5 held, with reasons in the spec; finding 3 corrected.
Tested: unit tests, system suite (security test checks the purge), telemetry test, fork checks.
Personal-data catalog, Phase 3a.
- New installs only (no roles yet): ban periods 30 d (D2), spam samples 90 d (D3), Pyzor off (D4), traces 14 d (D6). Each singleton is read, changed, written back whole.
- D7: new webhooks default to include with no events (Rust + schema default). Stored webhooks keep theirs.
- Daily clean-up removes expired bans.
- D1 and D5 held, with reasons in the spec; finding 3 corrected.
Tested: unit tests, system suite (security test checks the purge), telemetry test, fork checks.
Personal-data catalog spec, defaults D2, D3, D4, D6 and D7 (settled
2026-09-28, new installs only):
- D2: automatic IP bans expire after 30 days instead of never; D3:
spam training samples, whole messages, are kept 90 days instead of
180; D4: Pyzor, which sends a digest of each message's text to a
public server, is off; D6: delivery history is kept 14 days instead
of 30. Written on the first boot of a new install only -- one with no
roles yet, the same test the built-in roles use -- by reading each
singleton, setting these fields and writing it back whole. A server
with roles keeps its settings, saved or default.
- D7: a webhook created from now on starts with the include policy and
no events, so it sends nothing until events are chosen (Rust default
and schema default, marked). The registry stores every field, so
existing webhooks keep their policy.
- Expired bans are also removed by the daily data clean-up. They
already stopped blocking and were deleted when settings next loaded;
a server that seldom reloads kept them.
D1 (log retention) and D5 (the hashed-address blocklist off) are held,
and the spec says why: x:TracerLog is stored inside x:Bootstrap with a
field after it, so adding one changes that object's stored format; and
the spam-rules loader D5 touches is being reworked by the v0.16.24
import. The spec also corrects finding 3: expired bans were deleted on
settings load; bans were permanent only because no period is set.
Tested: unit tests for the new-install values and that everything else
in each singleton stays; the system suite, whose security test now
purges an expired ban and checks its record is gone; the telemetry
test; common's unit tests; fork checks.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Personal-data catalog, Phase 3a.
Tested: unit tests, system suite (security test checks the purge), telemetry test, fork checks.