v0.5.0

The release in which the ledger can be counted. How many there are, where they are
concentrated, how much has been minted lately — the figures an operational conversation
needs first are now available in the same shape from the CLI, the API and the admin
interface.

Counting happens in exactly one place. If the three entrances each wrote their own
aggregate, the same "count" would differ depending on where you looked — the worst
kind of drift.

Totals are limited by reach too: an organisation sees its own shoulders, a NAAN
administrator its NAAN, because a total is itself a disclosure. And what was removed
after publication is counted apart from the total — that is the number of times the
promise was broken, and it does not belong buried inside a sum.

Added

• A way to see the ledger's numbers (arkhe stat, GET /api/stats with ark:read,
  and a Statistics page at /admin/stats):
  ARKs (public and reserved), withdrawn names, shoulders by status, organisations,
  clients, holds in force, minting over the last 24h / 7 days / 30 days, the first and
  last mint, and a breakdown per shoulder. The CLI takes --json for machines.

  Counting happens in one place (domain/stats.py). If the screen, the CLI and the
  API each wrote their own aggregate, the same "count" would differ depending on where
  you looked — the worst kind of drift. It is the same reason the filters live in
  queries.py, and a test holds the three entrances to the same numbers.

  The admin page is not a dashboard. This interface is a ledger, and what it owes the
  reader is not a big number — it carries no charts, and the space goes to keeping what
  was removed after publication apart from the total.

  Totals are limited by reach too. An organisation sees its own shoulders, a NAAN
  administrator its NAAN, the registration authority everything — a total is itself a
  disclosure, since how many identifiers an organisation holds is that organisation's
  business. --naan and --org only layer on the same filters the listing uses; they
  never widen the range.

  Withdrawn names are counted with those removed after publication kept separate.
  Retracting a reservation nobody saw and removing a name that was out in the world are
  different acts, and the second is the number of times the promise was broken. That
  does not belong buried inside a total.

  The cost is stated honestly. It costs time proportional to the number of rows —
  unlike the listing, which avoids counting by fetching one extra row, because there only
  the existence of more matters while here the number is the answer. What can be
  avoided is the number of passes: the published split, the first and last mint, the
  three windows and the holds are all aggregates over the same set, so conditional
  aggregation gathers them in a single pass (seven reads of ark written naively,
  two as written). That is not only for speed — counts taken separately drift apart as
  rows arrive, and a 24-hour figure that exceeds the 7-day one destroys trust in the
  whole page. Measured at about 110 ms over 300,000 ARKs: not an endpoint to poll.

---

日本語の変更履歴
· Full Changelog: v0.4.0...v0.5.0