docs: correct "never through a central server" claim in README#408
Closed
pstayets wants to merge 1 commit into
Closed
docs: correct "never through a central server" claim in README#408pstayets wants to merge 1 commit into
pstayets wants to merge 1 commit into
Conversation
The README stated application data flows 'never through a central server'. This is false for the symmetric-NAT case: peers that cannot hole-punch relay all application traffic through the beacon, as the protocol docs and IETF draft describe. Reword to state the direct-path default and the encrypted relay fallback explicitly. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D2boz7GoTW34JmzymSjCpf
Contributor
Author
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
The README intro states:
"Never" is inaccurate. Per the protocol's own documentation (concepts page, IETF draft
draft-teodor-pilot-protocol-01), peers behind symmetric NAT that cannot hole-punch fall back to an encrypted relay through the beacon — application traffic for those peers transits operator-run infrastructure. The same sentence also glosses over the fact that discovery, address assignment, trust-request relay, and NAT coordination all depend on the hosted rendezvous/beacon (a single coordination host in the defaultinstall.shconfig).Change
One-sentence reword: keeps the direct-path default, states the symmetric-NAT relay fallback and that the relay forwards opaque packets it cannot read (which is the genuinely defensible privacy claim).
Why it matters
The absolute claim is contradicted by the project's own docs and draft spec, and it's the kind of discrepancy technical evaluators check first. The accurate version is still a strong story — no need to overstate it.
🤖 Generated with Claude Code
https://claude.ai/code/session_01D2boz7GoTW34JmzymSjCpf