id: design: writer sets v2 — composable views, set algebra, federation (extends #5545) #5789

Summary

Design writer sets v2: composition and federation — views built from other views, writer sets shared and subscribed across servers, and set algebra over the v1 primitives — the step after the single-owner, single-view projection #5545 specifies.

Motivation

The writer-set design (#2238 spec, closed; #5545 implementation) is deliberately singular: one view owner, one signed writer set (idset.writer), one projection tuple, and a discovery query that returns the counted and uncounted sides grouped by author. Its founding rule — "ingest is a validity gate, never an authority gate; a view counts only its writer set" — is exactly what makes composition interesting and undesigned: the moment a user wants to build on someone else's view (subscribe to a curator's set, union two communities' sets, publish their own view as an object others can count through), v1 has no objects for it. Tree state today is types and encoding only (idset.rs); v1 projection is still being implemented. That is the right order — but the v2 design should exist before v1's shapes ossify, because composition constrains representation: whether a view can reference another view, and what a set entry pointing at a set means, are decisions that are cheap now and expensive after #5545's encoding freezes.

Sketch

• View-as-object: a view (or its counted projection) published as a signed object others can reference — what exactly is referenced (the set? the tuple? a snapshot at a frontier?) and what the referencing view counts when the referenced view changes.
• Set algebra: union/intersection/difference over writer sets as derived sets with provenance — exclusions still win; derivation chains are auditable back to signed originals; cycles refused by construction.
• Federation: writer sets whose entries name authors known only on other servers — resolution through id: design: Querying local and remote ID servers v1 #5675's remote query and id: design: ID selective sharing and foreign data-store adapters v1 #5672's selective sharing; what a set may claim about authors the local server has never seen.
• Discovery v2: discovering views and sets (not just subjects) — who curates well is itself a discovery problem; the uncounted-side honesty rule extends: a derived view must be able to show what its sources excluded.
• Abuse shape: composition as an amplification vector (a popular view silently re-counting a flood) — rate/volume posture, composing with id: design: abuse-control primitives v1 for ID comms #2033's abuse primitives.

Open questions

• Is a derived view's projection still a pure function of a tuple (v1's purity rule), and what extends the tuple — source view frontiers per source?
• Retro-import (include_history) through a derivation chain: whose history flag governs?
• Do derived sets need their own signing owner, or is derivation unsigned-but-reproducible?

Relations

Parent: epic #2056. Extends: #5545 (v1 projection + discovery), #2238 (v1 spec). Relations: #5672 (selective sharing), #5675 (remote query), #2033 (abuse primitives), #5732 (typed similarity/recommendation — views are a signal source), and the GUI design (counted/uncounted rendering is where composition becomes visible). Filed in the 2026-11-04 gap pass (WS-F) as a version-ladder design.