This is an open contribution resource. The goal is an honest, well-sourced overview that helps everyone understand what each privacy protocol does and where things are headed.
-
Cite your sources. Every tick, partial tick, or dash should be traceable to official documentation, a protocol spec, or a verifiable onchain fact. Add reusable source links to
sourceRefsindocs/data.js, then cite them from the relevant footnote. Use the PR description for extra context, not as the only place evidence lives. -
Be accurate. If a protocol doesn't have a capability yet, that's a dash — and that's fine. Partial ticks exist for real caveats, not for spin. The grid is more useful when it reflects reality.
-
Scope changes clearly. One PR should do one thing: update an entry, add a protocol, improve a definition. Don't bundle unrelated changes.
All grid data lives in docs/data.js. The website renders the rows, footnotes, and definitions from that file, so don't edit the table rows in docs/index.html by hand.
- Find the protocol in
fullProjects(Full Grid) orglanceProjects(At a Glance) - Change
true,"partial", orfalsefor the relevant property - If adding a partial tick, add a sourced footnote to
fullFootnotesorglanceFootnotesand map it in the protocol'sfnMap - Update the
definitionslist if the rationale text needs to reflect the change - If your change affects visible counts or summary copy, update the matching text in
docs/index.htmlandREADME.md - Run
node scripts/validate-data.js - Preview locally from
docs/withpython3 -m http.server 8080
- Add a new object to
fullProjectsfollowing the existing format - Document all 17 properties with sources for each
- Add corresponding sourced footnotes for any partial ticks
- Add the protocol to
glanceProjects(At a Glance tab) with the 6 condensed entries - Update any visible count/copy references in
docs/index.htmlandREADME.md - Run
node scripts/validate-data.js - Preview locally
Open an issue first. New properties affect every protocol row, so discuss whether the property is meaningful and how each protocol should be documented before writing code.
Update the relevant entry in the definitions list. Keep the tone factual and concise.
Keep docs/data.js readable and explicit. This project favors straightforward data structures over clever abstractions. Footnotes use sourced("caveat text", ["source-id"]); add new source IDs to sourceRefs.
Before opening a PR, run this from the repo root:
node scripts/validate-data.jsPRs will be reviewed for:
- Accuracy of claims (sources required)
- Consistency with the existing format
- Whether the site data and visible copy stay in sync