Positioning decision — jspod focuses on single-user personal pods

Context

While walking the first-run experience and planning the work in #1, a clearer framing emerged for what jspod is for — and what it isn't.

Decision

jspod is the opinionated front door for the single-user personal-pod use case. One identity, one passkey, one WebID, one pod. Everything — defaults, CLI help ordering, README intro, GIF, screenshots, seed content — is biased toward that audience.

Multi-user mode stays available behind --multiuser for anyone who wants it, but stops being a co-equal mode that every UX decision has to accommodate.

Why

The "60-second new user → working pod" north star from #1 is fundamentally a single-user story. Treating multi-user as co-equal forces compromises at every layer:

• Onboarding UX: an account picker or "are you registering or signing in" branch on first page load
• Seed content (Phase 4 of Friction removal: make first-run zero-friction from discovery to working pod #1): does /profile/card$.ttl belong to "the" user, or "a" user?
• Help text: --multiuser competes for headline space with the flags a personal-pod user actually cares about
• README screenshots & GIF (Phase 5 of Friction removal: make first-run zero-friction from discovery to working pod #1): a personal-pod GIF and a multi-user-admin GIF tell different stories
• Post-registration flow: "your pod is ready" vs "your tenant's pod is ready" are different copy

Picking one audience makes all those decisions easy.

The broader framing: layered ecosystem on JSS

This positions jspod as one of potentially several thin opinionated layers on top of JSS:

                        JSS (substrate)
                  protocol + storage + auth primitives
                              ↑
   ┌──────────────┬───────────┴───────────┬──────────────┐
   ↑              ↑                       ↑              ↑
 jspod         jsteam (?)              jsdev (?)      jsdemo (?)
single-user   multi-user host       headless / CI   preloaded for
personal      family / friends      no auto-open    talks & screencasts

Each layer:

• Pins a JSS version
• Picks its own defaults
• Owns its own README, GIF, screenshots, and audience
• Adds its own "batteries" (seed content, post-install hints, etc.)

The substrate (JSS) handles the protocol; each layer handles the feel for a specific audience.

Tradeoff acknowledged: more layers = more packages to publish, version-pin, and document, and discovery splinters (a new user has to know which one to type). So each new layer earns its existence by serving a distinct audience the others would compromise on. We are not creating sibling layers preemptively — only if/when a real audience shows up.

What this changes in practice

For #1 execution and ongoing work:

• Defaults: single-user stays the default (already true in index.js)
• Help output: demote --multiuser from the headline options block to an "Advanced" section
• README intro: reframe to "Your personal Solid pod in one command" (matches Phase 5 of Friction removal: make first-run zero-friction from discovery to working pod #1's suggested tagline)
• README structure: lead with the personal-pod story; move the multi-user examples to an "Advanced / hosting for others" section near the bottom
• Seed content (Phase 4 of Friction removal: make first-run zero-friction from discovery to working pod #1): assume one user — /profile/card, /public/welcome, /inbox/, /private/ all belong to the user
• GIF / screenshots (Phase 5 of Friction removal: make first-run zero-friction from discovery to working pod #1): one registration, one WebID, one populated pod
• Comparison table: the "jspod vs JavaScriptSolidServer" table in README should emphasize audience not just features — jspod for personal, JSS for server operators
• No new multi-user features in jspod — if a multi-user need arises, the answer is JSS direct or (eventually) a separate sibling layer

Not in scope

• Removing --multiuser (we are keeping the escape hatch, just not optimizing for it)
• Creating sibling layers preemptively (jsteam / jsdev / jsdemo are illustrative, not planned work)
• Forcing a hard split — power users can always drop down to JSS

Acceptance

When this issue is resolved:

• A new visitor to the jspod README sees "personal pod" framing, not a generic "Solid server" framing
• The first-viewport CLI help shows the flags a single-user cares about
• The seed content and GIF demonstrate a one-person flow
• The "when to use what" section makes the audience split explicit: jspod for personal, JSS for server operators, future layers for other audiences

References

• Friction-removal umbrella: Friction removal: make first-run zero-friction from discovery to working pod #1
• jspod README (current intro is generic "Solid server" framing): see repo root
• JSS repo: https://github.com/JavaScriptSolidServer/JavaScriptSolidServer