fix: disclose registry/beacon dependency and relay fallback in P2P marketing copy#138
Open
pstayets wants to merge 1 commit into
Open
fix: disclose registry/beacon dependency and relay fallback in P2P marketing copy#138pstayets wants to merge 1 commit into
pstayets wants to merge 1 commit into
Conversation
The homepage 'how it works' lede claimed 'No external dependencies' and
the /for/p2p page claimed a universal zero-hop path ('No relay, no
gateway') and 'the only long-running service is the daemon'. All three
claims contradict the documented architecture: every node depends on the
hosted registry (address assignment, key storage, trust relay) and
beacon (STUN, hole-punching), and symmetric-NAT peers relay all traffic
through the beacon — as this same page's NAT section and FAQ already
state.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01D2boz7GoTW34JmzymSjCpf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Exact issue
Three claims on the homepage and
/for/p2pcontradict the product's own documented architecture:src/pages/index.astro('How it works' lede): "A thin registry for discovery, then data flows directly between peers. No external dependencies." — Every node depends on two hosted services: the registry (address assignment, key storage, trust-request relay) and the beacon (STUN, hole-punching, relay fallback).install.shdefaults both to the same operator-run host. "No external dependencies" is false as written.src/pages/for/p2p.astro('Zero-hop data path'): "Packets travel the exact network RTT between the two machines. No relay, no gateway, no broker queue." — This does not hold for symmetric NAT: the same page's NAT section says "Pilot auto-falls-back to an encrypted relay", and the FAQ JSON-LD on this page already concedes it. The headline claim and the page's own fallback documentation contradicted each other.src/pages/for/p2p.astro('No servers to run'): "The only long-running service is the daemon on each agent machine." — True for what the operator runs, but it hides that discovery/NAT traversal rely on the Pilot-operated registry and beacon. Reworded to keep the ops point while disclosing the dependency.Change
Accurate rewording only — no design or structural changes. The plain-text machine-UI twin (
src/pages/plain/p2p.astro) is updated in lockstep per CONTRIBUTING's parity requirement.Why it matters
The honest version of this story is already told elsewhere on the site ("A thin registry handles discovery — then agents connect directly"). Keeping absolute "no server / zero-hop / no dependencies" claims alongside it reads as a credibility gap to any technical reader who finds the registry/beacon in the docs or the hardcoded coordination host in
install.sh.🤖 Generated with Claude Code
https://claude.ai/code/session_01D2boz7GoTW34JmzymSjCpf