You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
JSS supports git over HTTP via git-http-backend. As git-on-Solid usage grows (agent workflows, versioned data, lightweight collaboration), JSS docs would benefit from a clear treatment of how git and Solid compose — and how they don't.
This issue proposes a docs page covering the architectural patterns and security surfaces involved.
The architectural question
Git and Solid are different protocols with different security surfaces:
Aspect
Solid
Git
Resource model
URL-addressable resources
Content-addressed objects (SHA-keyed)
Access control
Per-resource (WAC, ACP)
Per-repository
State boundary
All resources URL-accessible by design
.git/ is internal protocol state, not transport
Read pattern
GET single resource
git clone (full object graph in one operation)
Two patterns emerge:
Pattern A — URL-flattening
Store the working tree (including .git/) as Solid resources. Each file in .git/ becomes individually addressable via Solid's normal serving semantics.
Pros: No extra server tooling; uses Solid's native model.
Cons: Exposes .git/HEAD, refs, and packed objects as URL-accessible. Read access to any one yields the full repository history. Git's repo-level access model is replaced by Solid's per-resource ACL, which doesn't naturally express "all of .git/ is internal."
Pattern B — Protocol gateway
Serve git through git-http-backend (smart-HTTP), block direct .git/ URL access at the server layer.
Pros: Preserves git's repo-level access model; clients use the standard git clone/push/pull protocol; .git/ internals are not URL-addressable.
Cons: Requires server-side git tooling.
JSS implements Pattern B.
Why this matters
Mixing protocols by URL-flattening one into another is a recurring web anti-pattern (early CGI exposing .htaccess, filesystem-mapped HTTP servers leaking dotfiles). The general principle: a protocol's "internal state" boundary should not become another protocol's "publicly addressable" surface.
For git, this matters specifically because the entire repo history is always present in .git/. There is no way to use Solid's per-resource ACL to expose "just the latest version" — once any .git/object/... is reachable, the full DAG is reachable.
A new page under docs/ (e.g., docs/git-on-solid.md) covering:
Overview — use cases including agent workflows (cf. GitFork-style ephemeral repos, https://gitfork.app), versioned personal data, and lightweight collaboration
Two architectural patterns — the table above plus prose
Security comparison — what each pattern exposes; ACL/repo-level model mismatch under URL-flattening
JSS reference pattern — git-http-backend behind Solid auth, minimal worked example
Background
JSS supports git over HTTP via
git-http-backend. As git-on-Solid usage grows (agent workflows, versioned data, lightweight collaboration), JSS docs would benefit from a clear treatment of how git and Solid compose — and how they don't.This issue proposes a docs page covering the architectural patterns and security surfaces involved.
The architectural question
Git and Solid are different protocols with different security surfaces:
.git/is internal protocol state, not transportGETsingle resourcegit clone(full object graph in one operation)Two patterns emerge:
Pattern A — URL-flattening
Store the working tree (including
.git/) as Solid resources. Each file in.git/becomes individually addressable via Solid's normal serving semantics..git/HEAD, refs, and packed objects as URL-accessible. Read access to any one yields the full repository history. Git's repo-level access model is replaced by Solid's per-resource ACL, which doesn't naturally express "all of.git/is internal."Pattern B — Protocol gateway
Serve git through
git-http-backend(smart-HTTP), block direct.git/URL access at the server layer.git clone/push/pullprotocol;.git/internals are not URL-addressable.JSS implements Pattern B.
Why this matters
Mixing protocols by URL-flattening one into another is a recurring web anti-pattern (early CGI exposing
.htaccess, filesystem-mapped HTTP servers leaking dotfiles). The general principle: a protocol's "internal state" boundary should not become another protocol's "publicly addressable" surface.For git, this matters specifically because the entire repo history is always present in
.git/. There is no way to use Solid's per-resource ACL to expose "just the latest version" — once any.git/object/...is reachable, the full DAG is reachable.Prior work
.git/exposure: Security: Block access to dotfiles and directories (.git, .env, etc.) JavaScriptSolidServer#28git-http-backend: https://gist.github.com/melvincarvalho/054479068a699dcde97bbd9046ae247bProposed docs page
A new page under
docs/(e.g.,docs/git-on-solid.md) covering:git-http-backendbehind Solid auth, minimal worked example.git/,.env,.ssh/by defaultHappy to draft the initial page if this issue gets a green light.