Skip to content

Add anon-rpc and KPS as indexed entries - #37

Open
voltrevo wants to merge 2 commits into
ethereum:mainfrom
voltrevo:specs/anon-rpc-and-kps
Open

voltrevo wants to merge 2 commits into
ethereum:mainfrom
voltrevo:specs/anon-rpc-and-kps

Conversation

@voltrevo

Copy link
Copy Markdown
Member

Follows #36.

Two new folders, both role: indexed, both left at 0000 for a maintainer to number on merge.

Folder Shortname Type Domains Text
specs/0000-anon-rpc/ ANON-RPC interface read, write https://github.com/ethereum/anon-rpc/blob/main/SPEC.md
specs/0000-kps/ KPS protocol read, write https://github.com/ethereum/kps/blob/main/SPEC.md

anon-rpc specifies how a wallet or application makes anonymized RPC requests without trusting the endpoint serving them: a pluggable anon-client, pinned by the hash of its bundle rather than by where it was downloaded from, runs sandboxed away from the DOM, storage, cookies and signing keys, and reaches the network only through a small explicit capability API. The host gets back an ordinary fetch. Currently at version 0.3.1, draft.

KPS (Key Pinned Streams) identifies a peer by the hash of its self-signed certificate rather than by a CA-signed domain, and carries multiplexed reliable byte streams and datagrams over WebRTC or QUIC. It is entered on its own terms rather than as an appendix to anon-rpc — taking the certificate authority and the DNS root out of the path by which a client reaches anything is an Access Layer primitive in itself — and anon-rpc is simply the first spec here to sit on it. Currently at draft version 0.2.1.

Each entry is a pointer in the shape 5/ZK-PROOF-OF-PERSONHOOD uses: the notice blockquote naming where the text lives, then enough context that a reader of the registry knows what the spec is without leaving. Neither carries a CC0 waiver, matching that stub and governance.md — the text is not here to waive.

Notes for review

  • index_reason is the open question, and it is the one thing here worth arguing about. Both entries carry moved, which passes CI (moved only requires upstream to be set) but stretches the sentence in front-matter.md that reads it as "its text was hosted here and now lives in another standards body". Neither text was ever hosted here. dependency is not available as an alternative: build_registry.py builds depended_on from hosted specs only, so an indexed anon-rpc naming KPS in depends_on fails that check. Intake: anon-rpc (interface), pointing at ethereum/anon-rpc #36 lays out the three ways forward, including hosting the text here instead. Happy to rewrite for whichever you pick.
  • specs/0000-anon-rpc/ carries depends_on: [0], meaning specs/0000-kps/ in this same pull request, per step 4 of intake.md. Both need their 0s replaced on merge: 0000-kps takes one number, 0000-anon-rpc takes the other and points its depends_on at the KPS number.
  • python3 scripts/build_registry.py --check passes unchanged. Both specs sit at 0000, so registry.yaml and the README table are untouched by this pull request and will need regenerating once the numbers are assigned.
  • No implementations or tooling are linked, per process/README.md. Both upstream links point at the specification file, not at the repository root.

🤖 Generated with Claude Code

Two pointer entries, left at 0000 for numbering on merge. anon-rpc
specifies anonymized RPC through a hash-pinned client running in a
sandbox with an explicit capability API; KPS is the key-pinned transport
it reaches the network over, which stands on its own as an Access Layer
primitive rather than as an appendix to anon-rpc. Both texts are
maintained in their own repositories under the ethereum org, so each
entry is a notice naming where the text lives plus enough context to
read the registry without leaving it.

Both carry index_reason: moved, the only one of the two permitted values
that passes CI here — dependency is unavailable because build_registry.py
counts depends_on from hosted specs only. The intake issue puts the
choice to the maintainers.

@Meyanis95 Meyanis95 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!
I'll wait @phipsae review before merging.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants