Per-user content and user@host: the last two headline questions - #131
Merged
Conversation
…ver a prerequisite The headless-at-provider question narrows rather than closes: at least many apps must be usefully usable with no headless copy anywhere — either because they implicitly don't depend on always-on sync, or because asynchronous sharing through a storage backend covers their collaboration (the bucket path the storage layer builds and the #20 demo proves: ciphertext put/pull, offline authoring reconciled later, cold-start from the bucket alone). A design where basic collaboration silently assumes an always-on peer is out; the only part of the question left open is whether the powerbox version itself ships in v1.
…ust regime, developer-oriented The sixth headline open question closes as a direction: the home origin never serves per-user content by default, because the byte-identical model IS the trust story — a host that can serve one user different bytes is a host that can target them, and the accountless dividend plus the constant-digest monitoring predicate hold precisely because nothing user-specific varies. Where per-user serving exists at all it is an explicit opt-in to the lower trust regime already named as the third origin class (live-ish, user-controlled, untrusted, never sharing the framework origin), and the expectation on record is that the opt-in is developer-oriented — publishing one's own records and content — not an end-user surface.
…de it The last headline open question closes as a deferral with teeth: "nothing in v1" is the selection — contact exchange stays out-of-band — and the ruling's actual content is the guard, that nothing built meanwhile may foreclose user@host architecturally. In today's vocabulary: the per-user static records option stays adoptable (it is exactly the opt-in lower trust regime the per-user-content ruling specced), contact cards remain self-certifying artifacts whose delivery channel is orthogonal, and first-contact verification binds regardless of how the card arrived, so a future host-served introduction path inherits the existing backstop against prekey substitution rather than needing a new one.
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
2 participants
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 answers to the final two headline open questions in NOTES.md, from design discussion 2026-08-26. Direction, not final ruling, per the record's conventions. (Stacked on #130; collapses to two commits once it merges.)
Per-user content (in "Home origin contract"): the home origin serves per-user content never by default — the byte-identical model is the trust story, and the accountless dividend plus the constant-digest monitoring predicate hold precisely because nothing user-specific varies. Where per-user serving exists at all it is an explicit opt-in to a lower trust regime (the third origin class from Addressing: live-ish, user-controlled, untrusted, never sharing the framework origin), expected to be a developer-oriented option rather than an end-user surface.
user@hostdiscovery (in "Addressing and discovery"): deferred, with a guard — "nothing in v1", contact exchange stays out-of-band, and the ruling's actual content is that nothing built meanwhile may preclude it architecturally: the per-user records option stays adoptable (it is exactly the opt-in regime above), contact cards remain self-certifying artifacts whose delivery channel is orthogonal, and first-contact verification binds regardless of how the card arrived.Both open-questions entries now point at their sections — all seven headline questions carry recorded answers. Docs-only;
just checkpasses.Automerge armed per repo convention.