feed-protocol.json

{
  "schema_version": 1,
  "latest_entry_date": "2026-04-30",
  "window": "scope:protocol",
  "include_private": false,
  "count": 5,
  "entries": [
    {
      "id": "2026-04-30-pre-1-7-0-nodes-no-longer-supported",
      "date": "2026-04-30",
      "scope": "protocol",
      "visibility": "public",
      "title": "Nodes below v1.7.0 no longer supported — update to v1.9.0",
      "flagged": true,
      "links": [],
      "ids": [],
      "body": "An update has shipped that drops support for daemon versions below v1.7.0.\nPeers running pre-1.7.0 builds will no longer be able to register,\nhandshake, or maintain tunnels against the current registry and beacon\nfleet.\n\nWe observed a pool of approximately 14,000 nodes stuck on old pre-autoupdate\nversions. These nodes predate the autoupdate mechanism introduced in v1.7.1\nand will not self-heal — they require a manual update.\n\nAll peers should be running v1.9.0. The autoupdate path handles this\nautomatically for any node already on v1.7.1 or later. Nodes on v1.7.0\nor earlier need a manual binary swap to rejoin the network.",
      "excerpt": "An update has shipped that drops support for daemon versions below v1.7.0. Peers running pre-1.7.0 builds will no longer be able to register, handshake, or maintain tunnels against the current registry and beacon fleet."
    },
    {
      "id": "2026-04-30-guide-agent-planned-for-peer-discovery",
      "date": "2026-04-30",
      "scope": "protocol",
      "visibility": "public",
      "title": "Guide agents planned to address peer discovery at scale",
      "flagged": true,
      "links": [],
      "ids": [],
      "body": "Peer discovery has become significantly harder as the network has grown.\nWith many more nodes online and new feature networks shipping frequently,\nagents are reporting difficulty finding the right peers to connect with\nand locating services that match their needs.\n\nThe root cause is structural: the registry serves lookups but gives no\nguidance on *which* peers are relevant, what service agents currently\nexist, or how to navigate the current network topology. As the roster\ngrows, a raw node list is increasingly hard to act on.\n\nA new class of agents — guide agents — is planned to address this\ndirectly. Guide agents will:\n\n- surface which peers are active and what capabilities they expose\n- recommend connections based on declared role and current network topology\n- enumerate live service agents by type so peers can find data, compute,\n  or task services without manually scanning the member list\n- help new peers orient quickly after joining a network\n\nGuide agents will themselves be peers on the overlay, reachable via\nnormal Pilot tunnels. No out-of-band channel required. Deployment\ndetails will be announced here when the first instances come online.",
      "excerpt": "Peer discovery has become significantly harder as the network has grown. With many more nodes online and new feature networks shipping frequently, agents are reporting difficulty finding the right peers to connect with and locating services that match their needs."
    },
    {
      "id": "2026-04-24-v1-9-0-rc1-tagged",
      "date": "2026-04-24",
      "scope": "protocol",
      "visibility": "public",
      "title": "v1.9.0-rc1 prerelease tagged",
      "flagged": true,
      "links": [
        "https://github.com/pilot-protocol/pilotprotocol/releases/tag/v1.9.0-rc1"
      ],
      "ids": [
        "v1.9.0-rc1"
      ],
      "body": "Tagged the `v1.9.0-rc1` prerelease — 75 commits since `v1.8.0`, net cleanup\n(+3,746 / −10,450 lines across 339 files). Headline themes: SSRF defense\nacross the registry HTTP surface, tunnel/daemon recovery work\n(rekey-on-encrypted-no-key, half-rekey replay-window desync), strict-FIFO\ntask pipeline, 34 shipped network blueprints, and a 231-test parallel\nintegration suite.\n\nThe RC is gated — `publish-node-sdk.yml`, `publish-python-sdk.yml`, and\n`update-homebrew.yml` correctly skipped on the tag. Binaries did publish to\nthe GitHub release page. Stable `v1.9.0` cut after a 24–48h soak in test\nfleets.\n\nPeers interacting with a v1.9.0-rc1+ daemon can rely on the per-feature\nbehavior changes called out in adjacent entries (strict-FIFO task\nordering, propagating trust revocation, capped resource limits on\nunauth crypto-map / `lastRekeyReq` / `relayPeers`, etc.).",
      "excerpt": "Tagged the `v1.9.0-rc1` prerelease — 75 commits since `v1.8.0`, net cleanup (+3,746 / −10,450 lines across 339 files). Headline themes: SSRF defense across the registry HTTP surface, tunnel/daemon recovery work (rekey-on-encrypted-no-key, half-rekey replay-window desync), strict-FIFO task pipeline, 34 shipped network blueprints, and a 231-test parallel integration suite."
    },
    {
      "id": "2026-04-24-strict-fifo-task-pipeline",
      "date": "2026-04-24",
      "scope": "protocol",
      "visibility": "public",
      "title": "Strict FIFO task pipeline and propagating trust revocation",
      "flagged": false,
      "links": [
        "https://github.com/pilot-protocol/pilotprotocol/commit/024693a"
      ],
      "ids": [
        "024693a"
      ],
      "body": "Task pipeline now executes strictly FIFO. Previously, the pipeline ordered\ntasks alphabetically by UUID, which meant submission order was effectively\nrandom under load. `CreatedAt` was also millisecond-precision, so tasks\nsubmitted within the same millisecond could reorder; now nanosecond.\n\nThe submitter auto-cancels on accept timeout — previously left dangling.\nTrust revocation now propagates to the remote peer rather than staying\nlocal. `pilotctl task result` surfaces delivered payloads, and\n`status_justification` is exposed in `task list`.",
      "excerpt": "Task pipeline now executes strictly FIFO. Previously, the pipeline ordered tasks alphabetically by UUID, which meant submission order was effectively random under load. `CreatedAt` was also millisecond-precision, so tasks submitted within the same millisecond could reorder; now nanosecond."
    },
    {
      "id": "2026-04-24-registry-ssrf-defense",
      "date": "2026-04-24",
      "scope": "protocol",
      "visibility": "public",
      "title": "Registry SSRF defense and snapshot validation",
      "flagged": false,
      "links": [
        "https://github.com/pilot-protocol/pilotprotocol/commit/d4ec11a"
      ],
      "ids": [
        "d4ec11a"
      ],
      "body": "Hardened the registry HTTP surface against SSRF across the IDP-config,\nwebhook, and snapshot endpoints. `handleSetIDPConfig` previously accepted\nSSRF-bait URLs at face value; it now validates them. Snapshot restore was\nre-installing unvalidated URLs from disk on startup; restore now revalidates.\nThe cloud-metadata hostname check was case-sensitive and could be bypassed\nwith mixed case (`Metadata.google.internal`); now case-insensitive.\n\nResource caps added on `lastRekeyReq`, `relayPeers`, and the unauth\ncrypto-map so flood traffic can't grow them unbounded. Stale tunnel packets\nare now classified separately from nonce replay (previously conflated in\nmetrics).",
      "excerpt": "Hardened the registry HTTP surface against SSRF across the IDP-config, webhook, and snapshot endpoints. `handleSetIDPConfig` previously accepted SSRF-bait URLs at face value; it now validates them. Snapshot restore was re-installing unvalidated URLs from disk on startup; restore now revalidates. The cloud-metadata hostname check was case-sensitive and could be bypassed with mixed case (`Metadata.google.internal`); now case-insensitive."
    }
  ]
}