Skip to content

Who runs home origins: answered — both, from day one - #126

Merged
lannbot merged 1 commit into
mainfrom
design/who-runs-home-origins
Aug 26, 2026
Merged

Who runs home origins: answered — both, from day one#126
lannbot merged 1 commit into
mainfrom
design/who-runs-home-origins

Conversation

@lannbot

@lannbot lannbot commented Aug 26, 2026

Copy link
Copy Markdown
Collaborator

Records the answer to the first headline open question in NOTES.md ("Who runs home origins in practice"), from design discussion 2026-08-26. Direction, not final ruling, per the record's conventions.

New section "Who runs home origins" (after Origin topology):

  • Flagship instance at 1.0: project-affiliated, per-user subdomain isolation (alice.polyvisor.app shape) under a PSL-listed parent; possibly à la carte paid services later (turnkey storage backend first) — bill-paying and ecosystem-boosting, not the point.
  • Self-hosting first class: minimal (ideally zero) capability gap; two shapes — turnkey static deployment (Netlify-class, conformance checker Home origin contract: required headers, MIME, service-worker scope - and an origin conformance checker #2 as the gate) and full-stack (origin + iroh relay + storage backend, docker-compose-class). The genuine structural gap (per-user subdomains need wildcard DNS/cert control turnkey hosts don't delegate) is stated, and the checker should report which posture it verified.
  • Shells beyond the tab: webview app shell eventually; webextension in two separately-decidable roles — app shell (still question-marked) and visor trust root for hosted instances (the Code-Verify-shaped layer from Release integrity, grown from monitor to root).
  • Onboarding teaches the trust relationship: first-run/docs (User creation flow and first-run tutorial: the strip, petnames, and recognition, taught in chrome's voice #37) state what a host can and cannot do, in the user's language.

The answered bullet in "Open questions" now points at the section. Docs-only; just check passes.

Automerge armed per repo convention.

… degraded tier

The headline open question closes as a direction: 1.0 ships with at
least one project-affiliated public instance (per-user subdomains
under a PSL-listed parent, the accountless-multi-tenancy dividend
cashed; someday possibly a la carte paid services as the instance
paying its own bills), and self-hosting is first class with a
minimal-to-zero capability gap — turnkey static deployment gated by
the conformance checker, or the full stack (origin + iroh relay +
storage backend) docker-compose-style. The one structural gap is
stated rather than papered over: per-user subdomain isolation needs
wildcard DNS + cert control that turnkey hosts do not delegate.
Shells beyond the tab (webview app shell; a webextension as shell
and/or visor trust root for hosted instances) and the onboarding duty
— docs that teach what a host can and cannot do — are recorded with
their cross-references (#2, #4, #37, release integrity).
@lannbot
lannbot enabled auto-merge August 26, 2026 12:44
@lannbot
lannbot merged commit b16702f into main Aug 26, 2026
3 checks passed
@lannbot
lannbot deleted the design/who-runs-home-origins branch August 26, 2026 12:56
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants