What's built,
what's next,
what's not planned.
Siphr is being built in the open. This page tracks the work against the cryptographic claims on the rest of the site. If a claim isn't shipped yet, it's markedplannedand tied to a phase below. No vapor.
You can sign up, generate a real keypair, create a repo, and commit files from the browser.
Smart-HTTP transport for plain git pushis shipping in v0.3–v0.4. Today, private repos use the in-browser editor and folder-drop paths — every byte encrypted in the tab before upload.
↳ source · github.com/VisualActions/Siphr
Crypto, identity, and a place to put things
The cryptographic plumbing is real. Object writes go to Supabase; the server holds public material only.
- ✓WebCrypto identity: P-256 ECDH keypair generated client-side
- ✓Passphrase-wrapped private key (PBKDF2-SHA256 · 600k iter · AES-GCM)
- ✓Stable public-key fingerprints (SHA-256 of canonical JWK)
- ✓Repo-key wrap/unwrap (ECDH + AES-GCM)
- ✓Per-object AES-256-GCM with fresh nonce
- ✓Postgres schema (users / repos / refs / objects) via Supabase
- ✓Signup flow that actually wraps your private key locally
- ✓Dashboard reads /api/users + /api/repos (real data)
- ✓Cross-device sign-in via encrypted identity blob
The first real commit, end-to-end encrypted in the tab
The repo-create UI generates a fresh AES-256 repo key in the browser, wraps it to your public key, and stores ciphertext only. The empty-repo page is a real working in-browser editor.
- ✓/repos/new matches artboard 08 (step rail, name-availability, segmented visibility)
- ✓Toggle grid for commits/branches/issues/filenames + rotation cadence
- ✓Live server-view preview updates as toggles flip
- ✓isomorphic-git over Lightning FS in the browser
- ✓In-browser file editor with a working commit button
- ✓Folder drop via File System Access API · default-skip .git/.env/node_modules/
- ✓Each loose object encrypted with the repo key before PUT
- ✓Refs advance server-side after the upload finishes
- ✓/admin operator console + /featured curation
git clone + git push for public repos · v0.4 includes a private-repo helper
Smart-HTTP discovery returns 403 for private today; v0.3 implements the real upload-pack + receive-pack for public repos so plain `git push` works end-to-end. v0.4 ships a native helper for private.
- ○Smart-HTTP upload-pack (real packfile streaming) for public repos
- ○Smart-HTTP receive-pack with object validation for public repos
- ○File browser hooked to real objects (currently only public-repo tree is real)
- ○Amend / multi-commit support in the browser editor
- ○Native siphr-helper binary · intercepts plain push for private repos
- ○Per-commit signing with Ed25519 keys (separate keypair from the ECDH one)
~/.ssh.More than one key per repo
The wrap-to-recipient primitives already work for one person. This phase ships them for multi-collaborator repos and the painful case (revocation).
- ○Invite by public-key fingerprint · pending-invite handshake
- ○Wrap repo key to each accepted collaborator client-side
- ○Revoke → rotate repo key → re-encrypt every object on next push
- ○Issues / PRs with encrypted bodies (per-thread sub-key)
- ○Ed25519 signing for commit signatures
- ○Web of trust: mark another fingerprint as verified out-of-band
Make 'verify, don't trust' actually verifiable
A privacy product without verifiable claims is just a sticker. This phase ships the things that turn the marketing page into evidence.
- ○Recovery codes (8-word BIP-39-style) generated at signup
- ○Public-key transparency log · append-only · Merkle witness
- ○Reproducible build pipeline · published build hash · external reproducers
- ○/transparency wired to real data (currently illustrative)
- ○Per-repo audit log of key-events (add, rotate, revoke)
- ○AGPL-3.0 license on the repo (committed)
Audit, then doors open
An audit before launch isn't a flex — it's the only reason a stranger should trust the marketing page. Deliberately no fixed date.
- ○External crypto + threat-model audit (Trail of Bits or similar)
- ○Public bug bounty
- ○Operator console live (lib/admin.ts already scaffolded)
- ○Featured-projects program: surface verified orgs publicly
- ○Status page · uptime SLO published · honest about incidents
- ○Pricing committed (free for public + 1 private; paid for orgs)
The things that come after a launch worth caring about
Deliberately listed last. None of these matter if v0.4–v0.8 aren't real.
- ○Native git helper (encrypts on push) · community could ship this earlier
- ○Mobile-friendly browse (read-only first)
- ○GitHub mirror import · 'send my embargoed branch to Siphr' flow
- ○Webhooks (signed, scoped to public-key holders only)
- ○Org accounts with key-hierarchy (admin keys delegate to repo keys)
- ○Languages other than English in the UI
- ✗SSH transport — not planned · keys live in the browser, not ~/.ssh
- ✗Federated forge protocol (ForgeFed) — deferred · not enough adopters yet
- ✗AI-anything — out of scope on purpose · 'we can't read it' includes us
The deliberate absences.
Private keys live in the browser. We don't want a copy in ~/.ssh — that would double the attack surface for no security gain.
If we could reset your access by email, we could be compelled to. The whole pitch breaks. Recovery codes only.
The server holds ciphertext. Searching it is impossible without a key — by design. Search is client-side.
'We can't read it either' has to include us. Inference-time access is reading.
Try the scaffold.
Sign up. Make a repo. Lose your passphrase on purpose and confirm we can't recover it. File issues.
Audit the crypto.
lib/crypto.ts is ~280 lines. Read it. Tell us what's wrong. The threat model wins from being wrong loudly and early.
Build it yourself.
When v0.8 ships, we'll publish a build hash. Until then: clone, build, diff. Any mismatch is interesting.