Decide against an extension system; compact per-app runtimes instead - #207
Merged
Conversation
The proposal keeps coming back, so it needs an entry rather than a memory: a sealed, separately signed unit that bakes into a file like a language pack, so a heavy optional feature ships on its own clock. The immediate case was a PowerPoint exporter with a large vendored dependency; the wider case was that building it once would serve spaces and dash too. The multi-app half of that is the part worth writing down, because it reads as the strongest argument FOR and turns out to be the strongest against. Bytes multiply rather than amortize -- every app pays host, container and its own i18n -- and the cheapest host measured costs more than the entire spaces shell as it stands. Only review effort amortizes, which was never the expensive half. Meanwhile neither unbuilt app wants one: no extension-shaped feature in either design, one of them has ruled out shell-block work and forbids carried user code outright, and both solved their heaviest payloads with CompressionStream and DOMParser and no dependency at all. The economics invert once you follow the bytes into the file. An extension bakes into the DECK, so the exporting user pays the dependency AND the machinery -- worse than merging the dependency into core unchanged -- while everyone else still pays for the host. Break-even needs under ~13% of users to ever export, and for a PowerPoint replacement, interop is the adoption path. And the thing none of the design work noticed: three extension mechanisms already ship. The plugin/skill channel extends by recipe at zero shell bytes; the tray bridge extends capability at the host and reaches every file ever saved, including ones that predate it; the kernel facade shares implementation with no frozen surface. All three cost zero platform invariants. Confirms rather than supersedes the 2026-07-26 entry -- the carrier stays generic because that is good hygiene, not because a plugin system is pending. Records what this does not decide (kernelizing packs is still wanted, and three defects found while looking) and what would reopen it.
nyblnet
force-pushed
the
decide-no-extensions
branch
from
August 3, 2026 12:28
f870c3f to
ad00075
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Records the decision, so the next person to propose an extension tier finds the reasoning instead of rebuilding it.
The load-bearing part is that the multi-app argument reverses. It reads as the strongest case for building one — amortize the machinery over three apps — and measurement says the opposite: bytes multiply rather than amortize, the cheapest host costs more than the entire
bento/spacesshell as it stands (10,052 B), and only review effort amortizes. Neither unbuilt app wants one; both solved their heaviest payloads with browser primitives and no dependency.Second, the economics invert once you follow the bytes into the file. An extension bakes into the deck, so the exporting user pays the dependency and the machinery — worse than merging the dependency into core unchanged — while non-exporters still pay for the host.
Third, three extension mechanisms already ship (plugin/skill, tray bridge, kernel facade) and none of the design work named them.
Confirms rather than supersedes the 2026-07-26 entry: the carrier stays generic because that is good hygiene, not because a plugin system is pending.
Also records what this does not decide — kernelizing
packs.tsper app is still wanted by both future apps, and three defects turned up while looking (offline mode does not gate pack fetches althoughdocs/security.mdsays it does; the shell-block registry is single-slot; an unparseable block is deleted permanently on the next save) — and the conditions that would reopen it.