Add PiProof to the PiOS library list

[EslaM-X]

Add PiProof to the PiOS library list

Hello @aurelienshz and Pi Core Team,

I would like to add my open-source project to the PiOS SDK/library list, following the steps in the README.

Field	Value
Category	SDK
Title	PiProof
Description	Portable verifiable proofs (PEP/1 protocol): Ed25519-signed event proofs any party can verify against their own trusted state — canonical schemas, replay protection, KYC/Mainnet eligibility gating, Trust Policy Engine, content-addressed registry roots, live Proof Explorer with tamper demo. Includes the AUREVIA transparency dashboard. Live demo: https://eslam-x.github.io/piproof/
Language/Framework	JavaScript / Node.js 18+ (ESM, zero dependencies)
Brainstorm project	PiProof

Compliance checklist

• The repository uses the unaltered PiOS license (copyright 2026 EslaM-X): https://github.com/EslaM-X/piproof/blob/main/LICENSE
• The required trademark notice is included in the README: "Pi, Pi Network and the Pi logo are trademarks of the Pi Community Company."
• Title follows the naming rule (not in the form "Pi App_Name")
• Repo: https://github.com/EslaM-X/piproof — v0.7.2: 69/69 tests across Node 18/20/22 on Linux & Windows, 20/20 adversarial vectors rejected, byte-for-byte reproducible test vectors, all CI actions pinned to full SHAs

What's inside

• PEP/1 protocol (src/) — canonical JSON, Ed25519, key rotation/revocation, atomic nonces (fsync-durable), eligibility registry
• PiProof/1 portable envelope — verify anywhere against your own registry copy; optional content-addressed registry_root
• Trust Policy Engine — post-crypto acceptance narrowing with rule-by-rule violations
• AUREVIA dashboard — live transparency surface over the verified pipeline; Proof Explorer + one-click tamper lab
• docs/TRUST_BOUNDARIES.md — honest trust-boundary analysis (registry authenticity roadmap, nonce durability contract, explicit non-audited status)

This project implements concepts endorsed during the PiRC1 review process (dynamic p_floor, x·y=k invariant tracking, escrow lock status, Transparency Dashboard).

Happy to adjust anything to match the list requirements.

[EslaM-X]

@aurelienshz — friendly review request when you have a moment. 🙏

Since opening this PR the project has moved forward substantially, and I've updated both the list entry above and this description:

• Renamed to PiProof (repo: https://github.com/EslaM-X/piproof) — PEP/1 stays the wire protocol; PiProof is the SDK/product surface
• Portable proof envelope with optional content-addressed registry_root — any party can verify against their own trusted state
• Trust Policy Engine — post-crypto acceptance narrowing (issuer allowlist, weight bounds, max age, KYC/Mainnet requirements)
• Live demo deployed: https://eslam-x.github.io/piproof/ (static transparency dashboard; interactive verifier runs via npm run app or the included Dockerfile)
• 69/69 tests across Node 18/20/22 × Linux/Windows · 20/20 adversarial vectors rejected · zero runtime dependencies (CI-enforced)
• Honest trust-boundary documentation in docs/TRUST_BOUNDARIES.md, including what is not proven yet

The one-line pitch: Don't trust the app. Verify the proof.

If anything in the entry needs reformatting to match the list conventions, tell me and I'll fix it immediately.

[EslaM-X]

Status update — PiProof has grown substantially since this PR was opened, so here is a summary for reviewers:

Latest release: v0.12.0 (full changelog: https://github.com/EslaM-X/piproof/blob/main/CHANGELOG.md)

• Portable proofs (PiProof/1) + Trust Policy Engine — any party can re-verify against their own trusted state;
  px piproof passport-verify proof-passport.json --registry registry.json\
• AUREVIA Proof Passport — Issue / Export / Import / Verify / Share (short public links + pure fragment links), tamper detection, one-click 60-second guided demo
• Dispute Engine — adjudication chain with three honest outcomes only: VALID / INVALID / UNVERIFIABLE
• Cross-application proofs — independent issuers share one verifier epoch; multi-issuer passports
• AI Agent Evidence — signed agent actions become portable, independently verifiable audit trails
• Horizontal scaling — zero-dependency Redis nonce store (hand-written RESP2 client, atomic SET NX claims across instances)
• Reproducible performance —
  pm run bench: ~7,300 verified proofs/sec single-core sequential full pipeline (p50 0.125ms), no mocks
• Honest documentation — threat model, traceability matrix (requirement↔code↔test↔attack), open-questions register answering the ten hardest critiques, and a transparency-log design draft prepared for external review

Quality gates: 103/103 tests · 20/20 adversarial vectors rejected · byte-deterministic vectors cross-verified in Python · CI on Node 18/20/22 × Ubuntu/Windows · zero runtime dependencies.

Live demo & dashboard: https://eslam-x.github.io/piproof/
Repo: https://github.com/EslaM-X/piproof

Happy to adjust category/description fields if the maintainers prefer.

[EslaM-X]

Status update — v0.13.0 shipped (releases)

Since the summary above, a new release landed converting an external professional review point-by-point into concrete artifacts:

• Protocol: explicit binding classes — every proof is now verifiably EPOCH_BOUND (cryptographically pinned to one registry generation) or LOCAL; relying parties can enforce require_epoch_bound in policy. Passports aggregate binding honestly (EPOCH_BOUND/LOCAL/MIXED).
• Canonicalization: formally specified as the PiProof Canonical Profile v1 (deliberately distinct from RFC 8785 JCS) with 15 interop vectors reproduced byte-exact by two independent implementations (Node + pure-Python stdlib, CI'd on Py3.10/3.12 × Linux/Windows).
• Honesty layer: nonce-store deployment matrix (FileNonceStore explicitly not distributed replay protection; Redis requires one strongly consistent authority), Dispute Engine renamed to what it is (deterministic evidence adjudication), Policy Engine scope documented as a v1 narrowing checklist, pseudonymization≠anonymity stated, and a full MATURITY.md evidence register: reference implementation ✅ / security-engineering prototype ✅ / production infrastructure ❌ — v1.0 stays gated on external audit.

Verification: 110/110 tests · 20/20 attacks rejected · 15/15 canonical vectors × 2 languages · CI green across Node 18/20/22 + Python 3.10/3.12.

Next in flight: the developer layer — installable SDK surface (JS + Python), named versioned policy presets (merchant-v1, agent-payment-v1, …), a one-call decision endpoint (the "Verify with PiProof" button backend), and piproof:// proof links.

[EslaM-X]

Full update through v0.14.0 (releases · live roadmap)

Two releases landed since the last comment, completing both an external-review hardening pass and the developer layer:

v0.13.0 — External-review hardening

A professional critique was converted point-by-point into concrete artifacts:

• Binding classes: every proof is now explicitly EPOCH_BOUND (cryptographically pinned to one registry generation) or LOCAL; policies can enforce require_epoch_bound; passports aggregate honestly (EPOCH_BOUND/LOCAL/MIXED).
• Canonicalization formally specified as the PiProof Canonical Profile v1 (deliberately distinct from RFC 8785 JCS) with 15 interop vectors reproduced byte-exact by two independent implementations (Node + pure-Python stdlib, CI'd on Py3.10/3.12 × Linux/Windows).
• Honesty layer: MATURITY.md evidence register (reference implementation ✅ / security-engineering prototype ✅ / production infrastructure ❌), nonce-store deployment matrix, Dispute Engine renamed to what it is (deterministic evidence adjudication), Policy Engine scope documented as a v1 narrowing checklist, pseudonymization ≠ anonymity stated.

v0.14.0 — Developer layer ("Verify with PiProof" in five minutes)

The adoption story made real for any Pi app — merchant, marketplace, game, agent, community:

• JS SDK (zero deps): createVerifier({registry, nonceStore}).decide(proof, {policy:'merchant-verification-v1'}) → deterministic ALLOW | DENY with reasons and violations.
• Named policy presets: frozen versioned defaults callable by name — merchant-verification-v1, marketplace-seller-v1, agent-payment-v1, community-member-v1, reward-eligibility-v1.
• Decision API: POST /api/decide shares replay state across endpoints; self-contained piproof://v1?p=… proof links; preset-aware verify endpoints.
• Python SDK (stdlib only): independent implementation of the same pipeline — from-scratch Ed25519, canonical profile with raw-key sort parity — Node↔Python agreement tested end-to-end in CI.
• Guide: docs/SDK.md

Current verification posture

126/126 tests · 20/20 attacks rejected · 15/15 canonical vectors × 2 languages · Ed25519 cross-verification · CI green on Node 18/20/22 + Python 3.10/3.12, Linux & Windows.

What would move this forward from our side: any signal that a PiOS listing review is possible, or pointers to the right reviewers. Everything needed to evaluate the work — spec, threat model, maturity register, runnable demos (npm run demo, npm run app) — is in the repo.

[EslaM-X]

PiProof v0.15.0 shipped in the same series (release):

• Fuzzing suite (6 seeded campaigns) that found & fixed a real canonicalization idempotence bug pre-release — Canonical Profile v1.1, vectors regenerated byte-exact in Node + Python
• Layer-governance checker enforcing the zero-dep audit surface structurally
• Engineering formal model: 12 security invariants with enforced-by/verified-by traceability
• Liveness-aware cross-process nonce locking (live-PID locks never stolen)
• Disclosed a V8 JSON.parse runtime divergence (unreachable in PiProof; documented for the ecosystem)

132 tests · 20/20 attacks · 15/15 interop vectors ×2 languages · FUZZ OK. v1.0 stays gated on external review.

[EslaM-X]

v0.16.0 shipped — https://github.com/EslaM-X/piproof/releases/tag/v0.16.0 (PR #27, CI green on Node 18/20/22 + Python 3.10/3.12 × ubuntu/windows + Go on both OSes)

This release answers the two "deliberately open" asks from the v0.15 update:

#13 — independent implementation → partially held. A third, from-scratch Go implementation (sdk/go/) now passes the full conformance matrix: 16 canonical interop vectors byte-exact, the valid event ACCEPTS, all 20 attack vectors reject with exact error codes. This proves the spec alone is enough to reimplement the protocol core. The remaining open half of #13 is author-independence — a maintainer outside this repo's authors.

#14 — mechanized verification → drafted. formal/piproof_gates.tla models the stateful heart of the G1–G9 pipeline (two racing verifiers, one shared nonce authority, atomic test-and-set) with INV-04 and INV-05 as TLC invariants — one command to machine-check once a TLC tooling job lands in CI. Honest status: hand-checked, not yet TLC-run; formal/README.md says so explicitly.

Also new:

• Normative conformance suite (npm run conformance, docs/CONFORMANCE.md): four-row matrix across all implementations, with claim rules ("passes at commit <sha>", never "certified").
• Seventh fuzz campaign (go-diff): Node vs Go differential through the CANC/PARSE driver protocol.
• Corrections to v0.15's Unicode story: ligatures have no canonical decomposition, so canon-012 does not discriminate sort orders; new vector canon-016 (Ç U+00C7 vs Å-sign U+212B) is the true v1.1 discriminator. Suite grew 15→16 vectors; cross-canonical.py was silently raw-sorting and now conforms to NFC-form sort.

Verification: 132/132 tests · layers clean · 20/20 attacks · 16/16 vectors ×3 languages · FUZZ OK incl. go-diff · conformance 4/4.

v1.0 remains gated on external review — row #13's author-independence half and public feedback are the standing invites.

[EslaM-X]

v0.16.1 shipped — https://github.com/EslaM-X/piproof/releases/tag/v0.16.1 (PR #28, all 13 CI checks green)

#14 mechanized verification: drafted → partially held. The TLA+ model is now machine-checked by TLC on every push and PR (new formal-tlc CI job): Temurin 21 + tla2tools v1.7.4 pinned to the official release SHA1; CI fails unless TLC reports "Model checking completed. No error has been found." over the complete 122-state space — INV-04 and INV-05 hold.

The first machine run immediately earned its keep by catching two real modeling flaws (Naturals→Integers unary-minus gap, and a non-atomic G8 snapshot choice that deadlock analysis exposed) — both fixed with design notes documented in formal/README.md.

Remaining open on #14: extending invariant coverage beyond INV-04/INV-05 toward INV-01…12. Remaining open on #13: author-independence (standing public invite). v1.0 remains gated on external review.

[EslaM-X]

v0.17.0 shipped — https://github.com/EslaM-X/piproof/releases/tag/v0.17.0 (PR #29, all 13 CI checks green)

The killer-use gap closes: verification with cryptographic certainty and zero disclosure.

• /gateway runs the complete G1–G9 pipeline inside the visitor's browser — the document never leaves the tab, and there is no endpoint anywhere that could receive it. The page's strict CSP (default-src 'none'; script-src 'self', no inline script) makes exfiltration a policy violation even by accident.
• The crypto core is a from-scratch pure-JS RFC 8032 Ed25519 + SHA-512 implementation (src/web-ed25519.js) — verify-only by construction, every constant derived rather than transcribed, exhaustively cross-checked against node:crypto in CI. That makes it the fourth independent verification implementation in the repository (Node / Python / Go / pure-JS).
• Honesty is structural: offline replay status renders gold UNVERIFIABLE — never green-washed; verdicts say "verified offline", not "verified". docs/PRIVACY_MODEL.md (normative) states the data inventory, keyed-pseudonym rotation, the gateway's honesty contract, and the honest limits.
• Host hardening shipped alongside: global security headers, /healthz, public /registry.json export, whitelist-only static route.

Verification: 139/139 tests · layers clean · 20/20 attacks · FUZZ OK · conformance 4/4 · TLC green.

Still open by definition: #13's author-independence half (public invite), v1.0 freeze (gated on external review).

[EslaM-X]

v0.18.0 shipped — https://github.com/EslaM-X/piproof/releases/tag/v0.18.0 (PR #30, all 13 CI checks green)

The Dispute Engine's honest disclaimer just became an honest implementation: decentralized arbitration is live.

What the court gives PiProof that nothing else in its class has:

• Judges are keys, verdicts are mathematics. A ruling exists only as an N-of-panel multi-signature over the exact tally bytes — strip one signature and it stops verifying. No "court operator" key exists anywhere.
• Trustless auditability. replayArbitration() re-verifies every ballot signature and recomputes every tally purely (no mutation) — anyone can audit any case and tampering surfaces as a named difference, never silence. The test suite pins the failure mode of the naive design (a mutating re-tally laundered tampered tallies).
• Real market mechanics without token escrow: published fee books, deterministic panel assignment (fee → reputation → id), reputation earned by consensus and lost by frivolous challenges.
• Challenge periods where a challenge IS a replay — corruption claims are settled by recomputation, and losing challengers pay reputation.
• The AI division with a constitution: AI argues; keys decide. Referee opinions are signed, advisory, hash-pinned into settlements — and referee keys structurally cannot vote.
• Settlement certificates ready for chains: byte-deterministic anchor payloads (pre-commitment tested), full tally proof inside, explicit adapter contract for broadcasters.

Try it: pep court-demo, or run node app/server.mjs and open /court.

Verification: 149/149 tests · layers clean · 20/20 attacks · conformance 4/4 · TLC green.

Still open by definition: author-independence half of #13, external review gating v1.0 (#11).

[EslaM-X]

PiProof v0.19.0 shipped — https://github.com/EslaM-X/piproof/releases/tag/v0.19.0 (PR #31, 21/21 checks green)

The Open Protocol Phase: the release where the project stopped asking "look what we built" and started proving "others can build it without us."

• SPEC.md: the whole protocol specified standalone — Canonical Profile v1.1, PEP/1, G1–G9 with normative error codes, h1 pseudonyms, envelopes, court wire format, conformance criteria.
• §11: Pi is an adapter, not a dependency — now proven by execution with a zero-Pi namespace (acme-logistics/container-42).
• Distribution across seven channels (npm · Python · Go · Rust · WASM · HTTP · CLI), all conformed against the same public vectors; the Rust crate passes all 16 canonical vectors + end-to-end verification in CI; the WASM build proves cross-call replay burn in Node.
• External implementation kit published: the bar for third-party verifiers, submission checklist, differential-fuzzing gate — plus an honest adopters ledger and a security-review process with a public findings register.

This is the infrastructure a Pi OS app store / agent registry would need to accept third-party verifiable evidence from any ecosystem, not just Pi's.