Path/package-scoped visibility — make "private" a property of a subtree, not a whole repo

[beardthelion]

The pitch

The README's roadmap already names whole-repo private-read enforcement:

"Implement private-read enforcement or remove private repo affordances until it exists."
"Implement repo write authorization: owner checks, protected branches, and UCAN capability checks."

I want to aim higher than the binary. "Private repo" is what every forge already does. The thing gitlawb is uniquely positioned to do — because identity is a DID and authorization is meant to be capability-based — is make visibility a per-path property: one repo, mostly public, with specific subtrees readable only by specific DIDs. Open source stops meaning all-or-nothing.

If you build whole-repo private as a one-off boolean now, path-scoping later is a data-model migration. If the visibility model is scoped from day one, whole-repo private is just the trivial case where the scope is /. Same work, strictly more capable, no migration. That's the argument for designing the ambitious version even if the first shipping slice is small.

What this unlocks

• Monorepo, one private package. Public packages discoverable and forkable; a proprietary or in-progress package gated to a DID set — without splitting the repo and shattering shared history.
• Hidden in-flight work. Peers mirror a push within ~30s today. A path-scoped visibility rule is the mechanism for "this change is real but not network-visible yet."
• Coordinated security disclosure. A fix lands in a gated path, opens to the world on disclosure day — same repo, same history, no out-of-band private fork.

This is the same all-or-nothing critique of git that's been going around lately (Theo's May 2026 source-control thread, which openly invited people to run with it) — but gitlawb has the identity and delegation substrate to actually express it, where git can't.

Honest read on what exists today

I've read the README; not pretending the pieces are done:

"Private repository read enforcement is not wired yet."
"UCAN chain validation and revocation are not complete."
"HTTP signatures prove identity, not full authorization policy."

So the substrate is identity that works (signed requests prove the requesting DID) and a token format that exists (gl ucan), with enforcement and chain-validation still ahead. That's fine — it means the design isn't boxed in yet, which is exactly when to get the visibility model right. I also see private-read (short-term #6) is sequenced after write authorization (#5); this proposal respects that ordering — read enforcement builds on the same authorization checks.

Approach

1. Visibility as a first-class, path-scoped concept in the repo's authorization model — a rule binds a path glob to a reader set (DIDs, later UCAN capabilities). Whole-repo private = scope /.
2. Enforcement keyed to the DID that signed the request — the identity layer already proves who's asking. Gate object/ref fetch on a visibility check against that DID. UCAN capability validation slots in as it matures instead of blocking the whole feature on full chain-validation/revocation.
3. gl surface in the shape of the existing gl protect: e.g. gl visibility set <path-glob> --readers <did>,<did>.
4. Ship order: whole-repo / case first to prove the enforcement path end-to-end, then narrow the scope to real subtrees — but the model carries path scope from commit one.

Questions for maintainers

• Is private-read / authorization enforcement claimed or in progress? If someone's on it, I'd rather build the path-scoping layer on top of their work than collide.
• Replication semantics for gated content — this is the real design fork, and the README doesn't specify it: should a peer lacking authorization (a) never receive the objects in gossip at all, or (b) receive hashes/metadata but get capability-required on content fetch? (a) is stricter; (b) is friendlier to the "code shouldn't disappear" durability goal but leaks existence. Which matches your intent — or is it per-rule?
• Path-scoped from the start — agree the data model should carry scope from day one to avoid a later migration, or is there a reason you'd want the whole-repo boolean as its own thing?
• Split: node owns protocol + enforcement, gl is a thin surface — right call?

To make the replication-semantics question concrete rather than theoretical, I sketched the whole-repo (scope /) slice and ran it end to end against a local node: anonymous fetch of a private repo → 404 (byte-identical to a missing repo, so existence doesn't leak), owner → 200, wrong-DID → 404, with a unit truth-table for the check.

https://github.com/beardthelion/node/tree/feat/private-read-enforcement

I'm not proposing it for merge. It only wires the is_public flag the node already stores but never checks on the clone path, and deliberately leaves path-scoping, the replication-semantics fork above, and the other read surfaces (gossip / IPFS / GraphQL) untouched. I'd want your direction on those — and to know this is unclaimed — before taking it any further.

[beardthelion]

I sketched the whole-repo (scope /) enforcement slice as a working demonstration and opened it as #24, so the replication-semantics and path-scope questions above are concrete rather than theoretical.

It is explicitly not a merge candidate (the PR body has a "What this does NOT do" section): IPFS and gossip still serve the objects ungated, authorization is owner-only with no reader sets, and it enforces the existing is_public boolean rather than a path-scoped model. It just proves the HTTP read-path enforcement end to end (anon → 404 byte-identical to a missing repo, owner → 200, wrong-DID → 404) so the one decision that unblocks the real feature is easy to answer:

For gated content, should a peer lacking authorization (a) never receive the objects in gossip/IPFS at all, or (b) receive hashes/metadata and get capability-required on content fetch? Pick a direction and I will build the path-scoping layer on top. Also happy to know if this is already claimed before taking it further.

#24

[beardthelion]

Phase 1 of this is now up as a concrete, tested PR: #25.

It makes "private" a property of a path subtree rather than a whole-repo boolean, enforced on the git read path via the node's existing DID identity and RFC 9421 signatures: visibility_rules (path_glob, mode, reader_dids), a tested visibility_check decision function, no-existence-leak 404s, an owner-only management API, and a gl visibility CLI. 260 tests, fmt and clippy clean.

Two pieces are deliberately deferred and flagged in the PR: subtree mode-B clone filtering, and gossip/IPFS enforcement. The latter depends on the one open question: for gated content, should an unauthorized peer (a) never receive the objects in gossip/IPFS at all, or (b) receive hashes/metadata and be capability-gated on fetch? Phase 1 does not depend on that answer, but Phase 2 does.