version control where commit doesn't mean publish to everyone
wip is a proposed VCS built on jj's change model, with cryptographic read scopes. Sealed changes, per-path access, universal undo, and it lives inside your existing git repo. This page is a design RFC. There is no code. We want you to poke holes before there is.
Free forever. Apache-2.0. Built on jj. Exit to plain git, anytime.
_
Simulated output. That's the point of this page: it shouldn't stay simulated if the design survives review.
§1 the problem
git has exactly one read permission: all.
Anything committed is readable by everyone with repo access, forever. Teams have normalized the consequences:
- Security fixes developed in out-of-band private forks, patch-over-email, ceremony outside the VCS.
- Monorepos split not for size (tooling solved that) but for access control, paid for in dependency hell.
- Secrets can't live in the repo, so every team bolts on a parallel universe: Vault, SOPS, sealed-secrets, .env files passed over Slack. Config drifts from the code that consumes it, and the drift causes outages.
- On every forge, "private repo" means the forge can read it. Private as policy, not as structure.
Separately: git's daily UX carries 20 years of accumulated fear. jj already proved a better model, working copy as a commit, no staging, no stash, undo for everything. Nobody has combined that model with cryptographic read scopes. That empty quadrant is the proposal.
§2 the design, six pillars
-
Sealed changes
wip commit --seal sec-team: content, message, and paths encrypted, the world sees an opaque blob.wip revealpublishes one key and the change goes public with the same hash. Embargoes become a native workflow. -
Standing path scopes
/paymentsreadable only by payments-team. Your .env versioned in the repo, readable only by you. Replaces the SOPS/git-crypt/.env layer. -
jj's proven model
Working copy is a commit. No staging, no stash. Conflicts never block. Universal undo.
-
Lives inside git + coach mode
wip init --coexistjoins an existing repo; colleagues and CI see plain git; git commands work and teach as they go.rm -rf .wip/exits completely. -
SQLite storage, filesystem as adapter
Headless API mode for CI and agents. The cross-platform bug zoo is quarantined at checkout, never committed as repo truth.
-
Server as optimization, never as trust root
Fully functional offline. Any dumb remote (GitHub, S3) carries ciphertext. It never needs your plaintext, structurally.
Full detail, key design decisions included, in the RFC.
§3 why now: agents
git gives your agent the keys to everything.
wip gives it a keycard.
Every agent tool today handles safety by asking nicely: system prompts, allowlists, "please don't read .env". wip doesn't ask. An agent invited without a scope's key holds ciphertext, not a rule it promised to follow. Every agent change is signed by a session key and carries its delegation chain. Delegation only narrows: no invitee, human or agent, ever exceeds the inviter, enforced by key wrapping, not policy.
Honesty rule, stated up front: the claim is never "the agent can't do damage". The claim is that damage is bounded (crypto scopes) and reversible (op log undo).
§4 what can kill this
Every pitch has a graveyard section. Most hide it. Here is ours, stated plainly, because you'll find these anyway and we'd rather you attack the hard version.
- Adoption gravity. Git won on network effects; hg and bzr died anyway. The entire coexist strategy is the mitigation, and it's still risk #1.
- Sealed content breaks consumers. Teammates can't build code they can't read. Mitigations designed, unproven at scale.
- Crypto review burden. Nobody should trust an embargoed 0-day to this before professional cryptographic review. "We rolled our own" is disqualifying in this market, so the audit is on the critical path.
Six more, stated just as plainly, in the RFC kill list.
§5 the hostile review
Before publishing, the design went through two rounds of adversarial review, hostile personas attacking the system and then the product. The full Q&A ships with the RFC. The hardest open wounds, honestly labeled:
If the hash covers ciphertext, the coexisting git side still contains ciphertext after reveal, so git blame, bisect, and grep stay blind to that change on the git projection. The wip side sees plaintext; the git side sees a pointer. Whether that trade is acceptable is a core open question of this RFC.
Metadata-only ("file changed, 40 lines") compiles nothing. The designed answer is scope boundaries aligned to the build graph plus granted build artifacts, and it is unproven. If this can't be made to work, the monorepo pitch shrinks to the secrets and embargo pitch.
Sealing needs a team; a solo dev gets jj's model, which jj already gives away. The bet is that sealed .env across your own devices plus undo plus coach is enough solo value. That bet is exactly what stage 0 measures, and if it's wrong, this dies cheap and early, by design.
No wrap row means the bytes are noise to you. Not a server checking a rule: the absence of a key. This holds for extensions, transports, servers, and agents alike. Transports never need, and never get, read capability on sealed scopes.
§6 status, honestly
exists
- full system design
- two rounds of hostile review + answers
- threat framing for the crypto layer
- this page
does not exist
- code
- a cryptographic audit
- any reason to trust real secrets to it yet
The plan is gated: if the design doesn't survive public review, or early users don't retain, this dies at stage 0. On purpose. What we're asking from you today is review, not adoption.
§7 poke holes
Break the sealing scheme. Find the metadata leak we missed. Tell us the build-graph answer can't work. The best outcome of this page is someone killing the design cheaply, before the code exists.