diff --git a/.github/workflows/publish-manifest.yml b/.github/workflows/publish-manifest.yml new file mode 100644 index 00000000..268e2ec6 --- /dev/null +++ b/.github/workflows/publish-manifest.yml @@ -0,0 +1,113 @@ +name: publish-manifest + +# Receives a `repository_dispatch` event of type `manifest-update` from +# `web4/.github/workflows/release.yml` after a tag ships. The event carries +# the rendered manifest in `client_payload.manifest`; this workflow merges it +# into `public/.well-known/latest.json` and commits to main, which triggers +# the Cloudflare Pages deploy. +# +# Merge rules: +# - `latest_stable` is only advanced when the incoming manifest is for a +# non-prerelease tag (`is_prerelease == false`). RC tags update only +# `latest_prerelease` and `channels.edge`. +# - `platforms` is replaced wholesale with the incoming map for the tag. +# - `updated_at` is taken from the incoming manifest. +# +# Manual trigger (`workflow_dispatch`) is available for the case where the +# dispatch from web4 was dropped (missing token, transient 5xx) and the +# operator needs to nudge the manifest forward by hand. + +on: + repository_dispatch: + types: [manifest-update] + workflow_dispatch: + inputs: + manifest: + description: 'Inline manifest JSON (overrides the dispatch payload path)' + required: true + +permissions: + contents: write + +jobs: + merge-and-commit: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@v4 + with: + ref: main + fetch-depth: 0 + + - name: Resolve incoming manifest + id: incoming + env: + DISPATCH_MANIFEST: ${{ toJson(github.event.client_payload.manifest) }} + MANUAL_MANIFEST: ${{ inputs.manifest }} + run: | + if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then + echo "$MANUAL_MANIFEST" > /tmp/incoming.json + else + echo "$DISPATCH_MANIFEST" > /tmp/incoming.json + fi + jq . /tmp/incoming.json > /tmp/incoming.pretty.json + cp /tmp/incoming.pretty.json /tmp/incoming.json + echo "incoming manifest:" + cat /tmp/incoming.json + + - name: Merge into public/.well-known/latest.json + run: | + INCOMING=/tmp/incoming.json + CURRENT=public/.well-known/latest.json + mkdir -p public/.well-known + if [ ! -f "$CURRENT" ]; then + # First-ever publish — start from the incoming manifest, but + # rewrite the prerelease-aware fields into their final names. + jq '{ + "$schema": "https://pilotprotocol.network/.well-known/latest.schema.json", + "updated_at": .updated_at, + "latest_stable": (.proposed_stable // ""), + "latest_prerelease": (.proposed_edge // .tag), + "channels": { + "stable": (.proposed_stable // ""), + "edge": (.proposed_edge // .tag) + }, + "release_notes_url": .release_notes_url, + "homebrew_formula_url": .homebrew_formula_url, + "platforms": .platforms + }' "$INCOMING" > "$CURRENT" + else + jq --slurpfile inc "$INCOMING" ' + . as $cur | + $inc[0] as $i | + { + "$schema": ($cur["$schema"] // "https://pilotprotocol.network/.well-known/latest.schema.json"), + "updated_at": $i.updated_at, + "latest_stable": (if $i.is_prerelease then $cur.latest_stable else $i.proposed_stable end), + "latest_prerelease": ($i.proposed_edge // $i.tag), + "channels": { + "stable": (if $i.is_prerelease then $cur.channels.stable else $i.proposed_stable end), + "edge": ($i.proposed_edge // $i.tag) + }, + "release_notes_url": $i.release_notes_url, + "homebrew_formula_url": $i.homebrew_formula_url, + "platforms": $i.platforms + } + ' "$CURRENT" > "$CURRENT.new" + mv "$CURRENT.new" "$CURRENT" + fi + echo "merged manifest:" + cat "$CURRENT" + + - name: Commit and push + run: | + if git diff --quiet public/.well-known/latest.json; then + echo "manifest unchanged — nothing to commit." + exit 0 + fi + git config user.name "pilot-release-bot" + git config user.email "release-bot@pilotprotocol.network" + TAG=$(jq -r '.latest_prerelease // .latest_stable // "unknown"' public/.well-known/latest.json) + git add public/.well-known/latest.json + git commit -m "manifest: bump to ${TAG}" \ + -m "Triggered by upstream release workflow." + git push origin main diff --git a/public/.well-known/latest.json b/public/.well-known/latest.json new file mode 100644 index 00000000..29a4ee13 --- /dev/null +++ b/public/.well-known/latest.json @@ -0,0 +1,30 @@ +{ + "$schema": "https://pilotprotocol.network/.well-known/latest.schema.json", + "updated_at": "2026-05-28T14:00:00Z", + "latest_stable": "v1.10.5", + "latest_prerelease": "v1.10.5", + "channels": { + "stable": "v1.10.5", + "edge": "v1.10.5" + }, + "release_notes_url": "https://github.com/pilot-protocol/pilotprotocol/releases/tag/v1.10.5", + "homebrew_formula_url": "https://github.com/pilot-protocol/homebrew-pilot/raw/main/Formula/pilotprotocol.rb", + "platforms": { + "darwin-amd64": { + "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-darwin-amd64.tar.gz", + "sha256": "eab41da1108068e965e4c500bfae6f5aa1b6a21d02b7feb3942fd2b6434fc3be" + }, + "darwin-arm64": { + "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-darwin-arm64.tar.gz", + "sha256": "125fe7c8b83ce89f53487ec0ac1fe22decd4defd4af2b42559809042e2083597" + }, + "linux-amd64": { + "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-linux-amd64.tar.gz", + "sha256": "b062e355f24d85b884345de396398cd95d5c70fd44d23a9633c1bbcd3003022b" + }, + "linux-arm64": { + "url": "https://github.com/pilot-protocol/pilotprotocol/releases/download/v1.10.5/pilot-linux-arm64.tar.gz", + "sha256": "37428a4b08e6880cffca5049df872746358c41f9d63c25d5896446c48aa7e165" + } + } +} diff --git a/src/components/Nav.astro b/src/components/Nav.astro index 9bfac85a..7e1b4974 100644 --- a/src/components/Nav.astro +++ b/src/components/Nav.astro @@ -1,13 +1,12 @@ --- interface Props { - active?: 'home' | 'docs' | 'blog' | 'plans' | 'for'; + active?: 'home' | 'docs' | 'blog' | 'plans' | 'for' | 'tech' | 'apps'; } const { active } = Astro.props; const forLinks = [ { href: '/for/p2p', label: 'Direct P2P', desc: 'Peer-to-peer for AI agents' }, { href: '/for/mcp', label: 'MCP + Pilot', desc: 'Give your MCP servers a network' }, - { href: '/app-store', label: 'App Store', desc: 'Agent apps, one command to install' }, { href: '/for/networks', label: 'Networks', desc: 'Domain networks agents self-organize into' }, ]; @@ -48,8 +47,10 @@ const statusText = version ? `Network live · v${version}` : 'Network live'; data-track="nav_click" data-track-target="docs">Docs Blog + App Store Plans + data-track="nav_click" data-track-target="plans">Plans
-
+
{app.grants.length > 0 && ( diff --git a/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro b/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro index 1324ecba..004b0072 100644 --- a/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro +++ b/src/pages/blog/a2a-agent-cards-over-pilot-tunnels.astro @@ -1,11 +1,11 @@ --- import BlogLayout from '../../layouts/BlogLayout.astro'; -const bodyContent = `

Google's Agent-to-Agent (A2A) protocol is the first serious attempt at standardizing how AI agents communicate at the application layer. It defines Agent Cards for capability advertisement, a task lifecycle with streaming support, and JSON-RPC 2.0 as the wire format. It answers the question: what do agents say to each other?

+const bodyContent = `

Google's Agent-to-Agent (A2A) protocol is the first serious attempt at standardizing how AI agents communicate at the application layer. It defines Agent Cards for capability advertisement, a task lifecycle with streaming support, and JSON-RPC 2.0 as the wire format. It answers the question: what do agents say to each other?

What it does not answer is: how do they reach each other?

-

A2A assumes HTTP. Agent Cards are served at /.well-known/agent.json. Task requests are POST payloads. Streaming uses Server-Sent Events. This works when both agents have publicly routable URLs. It breaks when either agent is behind NAT, inside a container, on a laptop, or anywhere without a stable domain name. And that describes the vast majority of real agent deployments.

+

A2A assumes HTTP. Agent Cards are served at /.well-known/agent-card.json. Task requests are POST payloads. Streaming uses Server-Sent Events. This works when both agents have publicly routable URLs. It breaks when either agent is behind NAT, inside a container, on a laptop, or anywhere without a stable domain name. And that describes the vast majority of real agent deployments.

Pilot Protocol solves exactly this gap. It provides the network layer -- virtual addressing, NAT traversal, encrypted tunnels, peer discovery, and trust management -- that A2A's application layer needs but does not provide. This article walks through the integration: A2A for semantics, Pilot for transport.

@@ -68,7 +68,7 @@ const bodyContent = `

Google's // AgentCard represents an A2A Agent Card @@ -139,7 +139,7 @@ func main() { } // Serve the Agent Card at the A2A well-known path - http.HandleFunc("/.well-known/agent.json", func(w http.ResponseWriter, r *http.Request) { + http.HandleFunc("/.well-known/agent-card.json", func(w http.ResponseWriter, r *http.Request) { w.Header().Set("Content-Type", "application/json") json.NewEncoder(w).Encode(card) }) @@ -168,10 +168,11 @@ func main() { // Listen on Pilot's HTTP port (80) log.Printf("A2A agent serving at pilot://%s:80", pilotAddr) - drv.ListenAndServeHTTP(80, http.DefaultServeMux) + ln, _ := drv.Listen(80) + http.Serve(ln, http.DefaultServeMux) } -

Any peer agent on the Pilot network can now fetch this agent's capabilities by requesting /.well-known/agent.json over a Pilot HTTP connection. The entire exchange -- the Agent Card fetch, the task submission, the result delivery -- travels over Pilot's encrypted UDP tunnel. No public IP required. No DNS. No TLS certificate management. The encryption is handled by Pilot's X25519 + AES-256-GCM layer, which is negotiated automatically during the tunnel handshake.

+

Any peer agent on the Pilot network can now fetch this agent's capabilities by requesting /.well-known/agent-card.json over a Pilot HTTP connection. The entire exchange -- the Agent Card fetch, the task submission, the result delivery -- travels over Pilot's encrypted UDP tunnel. No public IP required. No DNS. No TLS certificate management. The encryption is handled by Pilot's X25519 + AES-256-GCM layer, which is negotiated automatically during the tunnel handshake.

@@ -184,7 +185,7 @@ func main() {
  1. Address resolution is trust-gated. An agent's Pilot address can only be resolved by peers who have completed a trust handshake. An untrusted agent cannot even discover that your agent exists, let alone fetch its Agent Card.
  2. Connection establishment requires mutual trust. Even if a peer knows your address, it cannot open a connection unless the trust handshake succeeds. The handshake is signed with Ed25519 keys and verified by both sides.
    3. -
  3. The Agent Card is served over the trusted connection. By the time a peer fetches /.well-known/agent.json, both agents have already authenticated each other. The card's contents are revealed only to verified peers.
    4. +
  4. The Agent Card is served over the trusted connection. By the time a peer fetches /.well-known/agent-card.json, both agents have already authenticated each other. The card's contents are revealed only to verified peers.

This creates a layered privacy model that standard A2A cannot provide. You control who sees your capabilities, not just who can submit tasks. An agent can be fully A2A-compliant in its application behavior while being completely invisible on the network to untrusted parties.

@@ -226,7 +227,7 @@ func main() {
  1. Discovery. The client agent resolves the server agent's Pilot address through the registry, optionally filtering by capability tags that match A2A skill IDs.
  2. Connection. The client opens a Pilot connection to the server on port 80. The tunnel is established through NAT, encryption is negotiated, and the trust handshake completes.
    3. -
  3. Card fetch. The client sends an HTTP GET to /.well-known/agent.json to verify the server's capabilities before submitting work.
    4. +
  4. Card fetch. The client sends an HTTP GET to /.well-known/agent-card.json to verify the server's capabilities before submitting work.
  5. Task submission. The client POSTs a JSON-RPC tasks/send request. Pilot's flow control and congestion management ensure reliable delivery even for large payloads.
  6. Streaming. If the task supports streaming, the server sends Server-Sent Events over the same HTTP connection. Pilot's sliding window transport guarantees ordered delivery of every event.
  7. Completion. The server returns the final task result over the established tunnel.
    8. @@ -240,17 +241,17 @@ func main() {

    One of the most powerful patterns that emerges from combining A2A and Pilot is multi-layer discovery. A client agent looking for a specific capability can search at both layers:

    - 
    // Step 1: Query Pilot registry for task-ready agents
-pilotctl peers --search "task-ready"
+  
    // Step 1: Find task-serving peers by hostname substring
+pilotctl --json peers --search "task"
 
-// Returns: list of Pilot addresses with capability metadata
-// 1:0000.0042.00A1  capabilities=[task-ready]
-// 1:0000.0042.00B3  capabilities=[task-ready]
-// 1:0000.0042.00C7  capabilities=[task-ready]
+// Returns: matching peers by address + hostname
+// 1:0000.0042.00A1  task-worker-a
+// 1:0000.0042.00B3  task-worker-b
+// 1:0000.0042.00C7  task-worker-c
 
 // Step 2: Fetch Agent Cards from candidates
 // Filter by A2A skill tags for "summarization"
-// use pilotctl connect <addr> <port> for raw TCP to fetch /.well-known/agent.json
+// use pilotctl connect <addr> <port> for raw TCP to fetch /.well-known/agent-card.json
 pilotctl connect 1:0000.0042.00A1 80
 pilotctl connect 1:0000.0042.00C7 80
 
@@ -260,7 +261,7 @@ func main() {
 // use pilotctl connect <addr> <port> for raw TCP
 pilotctl connect 1:0000.0042.00C7 80
    
 
-  
    Pilot's registry narrows the search to task-ready agents in the network. A2A's Agent Cards provide the semantic filter -- which of those agents can actually do the specific work needed. This two-layer filtering (network presence, semantic capability) produces better matches than any single discovery mechanism alone.
    
+  
    Pilot's peer search narrows to agents matching the hostname prefix in the network. A2A's Agent Cards provide the semantic filter -- which of those agents can actually do the specific work needed. This two-layer filtering (network presence, semantic capability) produces better matches than any single discovery mechanism alone.
    
 
   
    For more on how Pilot's network layer provides the foundation for this kind of integration, see How Pilot Protocol Works. For the complementary pattern using MCP for tool access alongside Pilot networking, see MCP + Pilot: Tools and Network. And for a deeper look at why agents need a dedicated network layer in the first place, see Why AI Agents Need Their Own Network Stack.
diff --git a/src/pages/blog/advanced-network-automation-tips-secure-ai-systems.astro b/src/pages/blog/advanced-network-automation-tips-secure-ai-systems.astro index 9e56ab68..a59a6fa7 100644 --- a/src/pages/blog/advanced-network-automation-tips-secure-ai-systems.astro +++ b/src/pages/blog/advanced-network-automation-tips-secure-ai-systems.astro @@ -179,7 +179,7 @@ const bodyContent = `

Agent communication security: best practices for AI developers

@@ -88,9 +88,9 @@ const bodyContent = ` @@ -39,7 +39,7 @@ const bodyContent = `

Encrypted data exchange for decentralized AI systems

@@ -149,14 +149,14 @@ const bodyContent = `

Encryption protocols for secure AI systems: A practical guide

@@ -178,7 +178,7 @@ const bodyContent = `

How mutual trust secures decentralized AI agent networks

@@ -145,7 +145,7 @@ const bodyContent = `

Legacy protocol integration for secure distributed AI

@@ -95,7 +95,7 @@ const bodyContent = `

Persistent network addressing for secure AI systems

@@ -231,7 +231,7 @@ const bodyContent = `