Decide upstream relationship: nosdav/browser ↔ linkedobjects/{browser,losos}

[melvincarvalho]

Problem

Three repos carry overlapping copies of the same source tree:

repo	role	activity
`nosdav/browser`	active fork — all recent work happens here	weekly commits
`linkedobjects/browser`	upstream candidate	only "Initial commit" (Mar 23)
`linkedobjects/losos`	upstream candidate (carries `panes/` and the LOSOS framework)	only "Initial commit" for panes; framework files do see updates (e.g. losos#16)

Affected file groups in all three:

• `panes/*` — sharing-pane, source-pane, terminal-pane, profile-pane, agent-pane, folder-pane, webledger-pane, playlist-pane, markdown-pane, todo-pane, schema-pane, pod-pane, home-pane
• `losos/*` — html.js, shell.js, store.js, registry.js, losos.js
• `lion/*` — vendored from elsewhere (`linkedobjects/lion`?)
• `mashlib.js`, `mashlib.css`, `index.html`

`nosdav/browser` is the file that gets deployed (`solid.social` self-hosts from this tree). The linkedobjects copies are byte-identical to the March snapshot for panes, drifted ~1.1KB+ from current nosdav/browser.

Why decide now

Every fix raises the question — and we keep answering it ad hoc:

• losos framework fixes: upstream first (PR Sync losos/html.js cache-validity fix from upstream (#15 / linkedobjects/losos#16) #4 mirrored losos/html: skip patch shortcut when cached DOM was wiped (#15) linkedobjects/losos#16). Worked fine, low cost.
• panes fixes (e.g. sharing-pane: login prompt for anonymous viewers (#8) #10 / sharing-pane anonymous prompt): only nosdav/browser because the patch is xlogin-specific and we don't know if linkedobjects uses xlogin.

The status quo is: "use judgment per file." That's coherent if everyone holds the rule, but it rots fast as the fork accumulates xlogin/JSS-specific assumptions that linkedobjects can't take.

Options

A. Fork cleanly — declare `nosdav/browser` the home

• Stop treating linkedobjects/{browser,losos} as upstream for panes / mashlib / index.html
• Keep upstream-first only for the LOSOS framework (`losos/*`), since that's a real shared library
• Update README / package.json to make the relationship explicit
• Pros: zero ongoing dance. Decisions stay local. xlogin-specific work doesn't need translation.
• Cons: linkedobjects copies become permanently stale; anyone who finds them gets confused

B. Sync linkedobjects from nosdav/browser

• One-way mirror: when nosdav/browser changes, push corresponding diff to linkedobjects
• Either manual PRs, or a CI job that mirrors selected paths
• Pros: linkedobjects stays a usable starting point for someone forking
• Cons: xlogin assumptions leak into linkedobjects (or need a translation layer); maintenance burden; nobody's actually consuming linkedobjects so the work is for ghosts

C. Sync nosdav/browser from linkedobjects

• Reverse: linkedobjects is canonical, nosdav/browser pulls + applies a thin xlogin adapter
• Pros: linkedobjects stays clean of xlogin/JSS specifics
• Cons: linkedobjects is currently inactive; would need someone to take it over. `nosdav/browser` deploy gates behind upstream merge cycles. `xlogin` adapter is non-trivial.

D. Merge the trees — collapse to one repo

• Ask linkedobjects org if they want to either absorb nosdav/browser as the active branch, or transfer ownership
• Pros: one repo, one history, no drift question ever again
• Cons: governance / org decision; depends on linkedobjects intent

Recommendation (informed by current state)

A for panes / mashlib / index.html, keep upstream-first for losos/.

The LOSOS framework is the only piece with a credible "shared library" story (it has its own issues, its own version-able surface). Panes are app-specific UI built against a specific auth lib (xlogin) and a specific server (JSS) — they were never going to live cleanly upstream without a translation layer nobody has time to maintain.

Concretely:

• Document this in nosdav/browser's README: "panes/, mashlib.*, index.html: home-here. losos/: vendored from linkedobjects/losos — fixes go upstream first."
• Stop the dual-source pretense for non-LOSOS files
• Existing linkedobjects/{browser,losos} `panes/` copies stay as the March snapshot — anyone forking starts from a known point in history

Acceptance

• Decide A / B / C / D
• Update nosdav/browser README to state the chosen relationship
• If A: also note in linkedobjects/{browser,losos} that the active version lives at nosdav/browser
• (If A) keep losos-mirror discipline: panes do not need upstream PRs, but losos changes do

Related: linkedobjects/losos#17 (duplicate source within that repo), #19 (npm publish).