{
  "count": 7,
  "peers": [
    {
      "peer": "red-flag-ai-pro",
      "observations": 2906,
      "distinct_tips": 2899,
      "first_seen": "2026-08-01T21:41:00.675260+00:00",
      "last_seen": "2026-10-04T12:15:22.266796+00:00",
      "hours_since_last": 0.3,
      "status": "current",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "bound",
      "bound_to": "https://www.redflagaipro.com/api/witness/tip"
    },
    {
      "peer": "mir",
      "observations": 644,
      "distinct_tips": 643,
      "first_seen": "2026-09-07T17:48:31.648013+00:00",
      "last_seen": "2026-10-04T12:05:00.555996+00:00",
      "hours_since_last": 0.4,
      "status": "current",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "bound",
      "bound_to": "https://mir.events/v1/transparency/tip"
    },
    {
      "peer": "praesidium",
      "observations": 660,
      "distinct_tips": 2,
      "first_seen": "2026-08-17T21:16:48.312383+00:00",
      "last_seen": "2026-10-04T11:40:48.460888+00:00",
      "hours_since_last": 0.8,
      "status": "current",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "bound",
      "bound_to": "https://chain4.thepraesidium.ai/api/witness/tip"
    },
    {
      "peer": "flavorflowstrategy.uk",
      "observations": 859,
      "distinct_tips": 199,
      "first_seen": "2026-08-12T21:42:23.803897+00:00",
      "last_seen": "2026-10-04T11:40:48.195320+00:00",
      "hours_since_last": 0.8,
      "status": "current",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "bound",
      "bound_to": "https://www.flavorflowstrategy.uk/witness.json"
    },
    {
      "peer": "agentenvelope",
      "observations": 1130,
      "distinct_tips": 11,
      "first_seen": "2026-09-09T21:43:28.590508+00:00",
      "last_seen": "2026-10-04T11:36:49.383650+00:00",
      "hours_since_last": 0.9,
      "status": "current",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "bound",
      "bound_to": "https://agentenvelope.io/witness/tip"
    },
    {
      "peer": "mir-verifier",
      "observations": 2,
      "distinct_tips": 1,
      "first_seen": "2026-09-23T06:15:28.797899+00:00",
      "last_seen": "2026-09-23T06:24:01.565776+00:00",
      "hours_since_last": 270.1,
      "status": "silent",
      "liveness": "self-consistent",
      "reachability": "reached",
      "name_status": "first-use",
      "bound_to": "https://mir.events/v1/transparency/verifier"
    },
    {
      "peer": "shango.in",
      "observations": 1,
      "distinct_tips": 1,
      "first_seen": "2026-08-25T08:25:14.818538+00:00",
      "last_seen": "2026-08-25T08:25:14.818538+00:00",
      "hours_since_last": 964.1,
      "status": "silent",
      "liveness": "self-declared",
      "reachability": "unrecorded",
      "name_status": "unbound",
      "bound_to": null
    }
  ],
  "witness_version": "1.4",
  "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 usable tip was obtained. That covers three different situations - no url was supplied, a url was supplied and could not be reached, or a url was reached and did not serve a valid tip. Read the 'reachability' field beside this one to see which. Before witness v1.4 those three were reported identically and the flag text asserted unreachability in all of them, which was wrong in the third case and is sealed in blocks from that period.",
    "reached": "An HTTP response was received from the submitted url. That is the whole claim. It does not mean the response was usable, that the endpoint belongs to the submitter, or that anything it served is true - only that the address answered.",
    "not-reached": "A url was supplied and no HTTP response was received - refused, timed out, would not resolve, or was refused by our own address rules before any request was made.",
    "not-attempted": "No url was supplied, so nothing was attempted. Distinct from 'not-reached', which means we tried and failed.",
    "first-use": "First time this name was seen with a url serving a valid tip, 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 url served a valid tip, so there is nothing to bind this name to. Note that this covers a url we never reached AND a url that answered with something we could not use - check the 'reachability' field to see which happened here. IMPORTANT: an unbound name stays claimable. Whoever submits it next WITH a url serving a valid tip 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.",
    "reached_is_not_parsed": "Reachability and liveness answer different questions and are recorded separately from witness v1.4. A url can be reached and still serve nothing we can use; before v1.4 both were reported as though the url could not be reached, which was false in that case and is sealed permanently in blocks from that period.",
    "unbound_costs_you_the_name": "A submission with no url serving a valid tip does not bind the name. Whoever submits it next with one 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."
}