{
  "count": 3,
  "peers": [
    {
      "peer": "red-flag-ai-pro",
      "observations": 808,
      "distinct_tips": 807,
      "first_seen": "2026-08-01T21:41:00.675260+00:00",
      "last_seen": "2026-08-20T00:11:11.665634+00:00",
      "hours_since_last": 0.0,
      "status": "current",
      "liveness": "self-consistent",
      "name_status": "bound",
      "bound_to": "https://www.redflagaipro.com/api/witness/tip"
    },
    {
      "peer": "flavorflowstrategy.uk",
      "observations": 21,
      "distinct_tips": 17,
      "first_seen": "2026-08-12T21:42:23.803897+00:00",
      "last_seen": "2026-08-19T17:59:03.878161+00:00",
      "hours_since_last": 6.2,
      "status": "stale",
      "liveness": "live",
      "name_status": "bound",
      "bound_to": "https://www.flavorflowstrategy.uk/witness.json"
    },
    {
      "peer": "praesidium",
      "observations": 4,
      "distinct_tips": 2,
      "first_seen": "2026-08-17T21:16:48.312383+00:00",
      "last_seen": "2026-08-18T11:18:34.287164+00:00",
      "hours_since_last": 36.9,
      "status": "stale",
      "liveness": "self-consistent",
      "name_status": "bound",
      "bound_to": "https://chain4.thepraesidium.ai/api/witness/tip"
    }
  ],
  "witness_version": "1.3",
  "what_this_list_is": "Parties that have submitted a tip to this deployment. Being listed here is not membership of anything, not endorsement of anything sealed in this chain, and implies no relationship beyond having sent a hash.",
  "status_vocabulary": {
    "current": "observed within the last 6 hours",
    "stale": "last observed between 6 and 48 hours ago",
    "silent": "not observed for more than 48 hours",
    "note": "These describe elapsed time since we last recorded an observation and nothing else. A peer that publishes on a human schedule rather than a timer will read stale between sessions, correctly. It is not a claim that anyone's endpoint was unavailable."
  },
  "legend": {
    "self-consistent": "The submitted url served exactly the submitted tip. Both halves came from the submitter, so this records self-consistency - NOT verification by us or any third party. Written as 'self-consistent' from witness v1.2 onward.",
    "confirmed": "The same check as 'self-consistent', under the name used before witness v1.2. It was renamed because the old name implied third-party verification that the check does not perform. Sealed blocks cannot be altered, so this record keeps the original word.",
    "live": "The url served a valid but different tip. A chain that moves between submitting and our fetching is the normal case, not a failure.",
    "self-declared": "No url was supplied, or we could not reach it. Taken on the submitter's word and checked by nobody.",
    "first-use": "First time this name was seen with a reachable url, so the name is now bound to it network-wide. Any later submission under this name from a different address records as conflict, permanently.",
    "bound": "Submitted from the same url this name was first bound to. Same operator, consistently.",
    "conflict": "This name has been submitted from a different address than the one it was first bound to. Not proof of theft - operators move hosts - but it is the event an auditor needs to see, and it is permanent.",
    "unbound": "No reachable url, so there is nothing to bind this name to. IMPORTANT: an unbound name stays claimable. Whoever submits it next WITH a reachable url takes the binding, and your own later submission would then read conflict. We cannot prevent that - an open endpoint has no way to tell two claimants apart - but a binding placed over a name that was submitted before is recorded as such. If the name matters, either submit with a url serving your tip, or use the signed lane at /x/peer/submit.",
    "unbound_costs_you_the_name": "A submission with no reachable url does not bind the name. Whoever submits it next with a url takes the binding. Choosing the accurate weaker liveness status therefore leaves the name claimable - a coupling worth knowing before it bites.",
    "signed_lane": "The signed lane at /x/peer/submit binds a name to knowledge of a shared secret, not to control of an address. Because the operator of this deployment holds the same secret, it closes third-party submission under your name and does not close operator submission under your name. That is a normal property of HMAC and it is stated rather than implied.",
    "anchoring": "Separately from the hash chain: this deployment submits its chain to the OpenTimestamps calendars for Bitcoin anchoring. Submission is not confirmation. A block is Bitcoin-confirmed only once a proof covering it has been upgraded and verified with a standard OpenTimestamps client. Check /x/ots/status for the state of the proof covering this block. Until that proof confirms, the guarantee here is the hash chain and not Bitcoin."
  },
  "note": "Silent peers are visible by design. A network you cannot audit is not a network. Nothing here proves identity - it shows how well each claim stood up to checking."
}