Program ecosystem (share, fork, gallery) — Phase 14 core topic (research + design)

Filed from the next-horizons discussion #1240, decided by Drew on 2026-11-05: all themes are planned. This issue is the core topic for Program ecosystem (share, fork, gallery). Its job is research and design — broaden the idea beyond what is already understood, set up multiple next steps, and produce implementation plans. No implementation starts here; the output is design documents and implementation issues.

Drew's principles for everything in Phase 14 (from #1240, 2026-11-05)

• Local-first is always the goal, AND a hosted version is intended: central coordination supporting a large graph of broadly accessible objects.
• Anything built must be completely usable by others hosting a small or large server themselves. P2P-hosted worlds and data behave the same as a large hosted public server; differences live in backend scale elements and access controls.
• Users connect to each other and transfer/interact directly wherever possible, so hosted resources are an offloadable backstop, not a requirement. The app must not technically need us to function. Collaborative / shared / federated / local-first / p2p.
• Our hosted instance is essentially public; other operators open theirs only as much as they want. Publishing paths: share to a big server, publish on pkarr, or self-host. All comms through iroh on the backend; first-class clients.

The idea, broadened

Programs are the platform's content. Today they are files you have. An ecosystem asks how a program travels: authorship, versioning, signing, forking with attribution, template worlds, install-into-a-world in one click, and updates flowing to installed copies. Broaden with the trust model first (F12.17 provenance is the foundation) and the local-first rule: a gallery is a registry like any other — ours can be public, anyone can run one, and sideloading a .roc file must always work.

Research questions (first pass)

• Program identity: name + author key + version + content hash; what a fork records
• Install semantics: pinning vs tracking a channel; what an update may change without world-owner approval (ABI, F12.7)
• Template worlds: a world snapshot as a starting point — state, programs, roles included or stripped
• Gallery as registry: same protocol family as world discovery (T2), different object type

Dependencies and existing pieces

Builds on F12.7 ABI (#1064), F12.8 guest SDKs (#1065), F12.9 upgrades (#1066), F12.17 provenance (#1069). Registry protocol shared with the discovery topic.

Next steps — the version ladder

• v1 — first-iteration design — its own issue, filed in the same pass and linked in the first comment below
• v2 — outline: gallery & updates — its own issue, filed in the same pass and linked in the first comment below
• v3 — outline: public gallery — its own issue, filed in the same pass and linked in the first comment below
• v4 — outline: ecosystem at scale — its own issue, filed in the same pass and linked in the first comment below

Plus a standing rule for this topic: anything the research surfaces that doesn't fit v1–v4 gets its own issue (Drew's rule: every feature, concept, or idea gets an issue), and future investigations are listed as comments here rather than lost.

Sequencing

Design queue order: F12.4 provider registry (#1061) and F12.10 scheduling/quotas (#1067) designs land first; Phase 14 v1 designs then run hosted worlds → discovery → agents spike → the rest. Implementation follows Phase 13. The drop rule applies throughout: anything that proves blocked, wrong, or superseded gets parked or closed with a note — never a silent stall.

Acceptance criteria

• A research + design output exists for Program ecosystem (share, fork, gallery): design documents broadening the topic beyond the current understanding, per the Phase 14 principles in the body (local-first plus hosted coordination).
• Multiple concrete next steps are produced as implementation plans / implementation issues filed from this topic.
• No implementation starts under this issue itself (per its own charter).