**Note** from Bead: 874fce5b · [canonical source](https://redfish.acequia.io/guerin/.agents/874fce5b-9c8b-4b23-b2ed-429148c6c4b7/2026-04-23/notes/downstream-pattern.md) · session 2026-04-23 · discussion: Talk: 874fce5b
**Date:** 2026-04-23 **Context:** Architecture chat, Claude Code. Triggered by "what would you think if I said 'downstream geo.camera to gsd.live'". See [../chats/2026-04-23-ecology-architecture-chat.md](../chats/2026-04-23-ecology-architecture-chat.md). Peer to [paths-as-event-bus.md](paths-as-event-bus.md) and [self-assembling-wires/ecology.md](self-assembling-wires/ecology.md).
## What "downstream" means in this ecology Directional propagation of an upstream resource into a downstream consumer's namespace, as a continuous binding rather than a one-off copy. The canonical example: `geo.camera` authored and deployed by redfish, made available to Harvard GSD students and faculty by mounting it at a path under `gsd.live`. Upstream keeps flowing; downstream consumes. "Downstream" is the user-facing name for a bundle of concerns that together define **how value and obligation move through the commons**: - **Devops layer**: the mechanics of making the bits reachable - **Governance layer**: who authorized this flow and under what terms - **ACL layer**: how access rules translate across the binding - **Attribution layer**: who gets credit, recursively - **Transaction layer**: the binding as a formal, auditable event - **Economic/ledger layer**: append-only record of value flow, licensing, obligations A downstream binding without any one of these layers is either sloppy engineering (missing devops), unauthorized copying (missing governance), insecure exposure (missing ACL), erased authorship (missing attribution), unrecorded state change (missing transaction), or unbilled labor (missing ledger). All six are needed for a commons to sustain itself without collapsing into extraction.
## 1. Devops layer: bind/mount, don't copy The mechanism from [paths-as-event-bus.md](paths-as-event-bus.md) and the bind/mount discussion in the chat: - **Bind** the upstream subtree (or a filtered view of it) at a downstream path - **Agent-at-URI** at the mount point handles branding, filtering, identity bridging, content transformation when needed - **Pull from stable tier**, not dev. Downstream should never see nightly schema churn; tier-selection is part of the binding contract - **Origin isolation** is automatic and intentional: `gsd.live` and `geo.camera` are separate origins, so localStorage/permissions/cookies are scoped per tier. A GSD user's state can't collide with redfish-internal dev state - **Upstream updates propagate automatically** through the binding. When an upstream resource apoptoses, the downstream binding reflects that without separate cleanup Not: `cp -r geo.camera gsd.live/geo.camera/`. That fork-and-diverge pattern is the DLA equivalent of coordination (stochastic accretion from elsewhere), and every downstream becomes a fragile island. Binding is the wire-network pattern: the branch extends, the structure carries flow, apoptosis at the source propagates.
## 2. Push vs pull semantics Two directions of initiative: - **Push**: upstream initiates. "Redfish is releasing v1.2 of geo.camera; propagating to all downstream bindings." Requires upstream to have write/bind authority at downstream locations, or for downstream bindings to subscribe to an upstream event stream. - **Pull**: downstream initiates. "GSD wants to adopt geo.camera for a spring-semester course; pulling a binding from redfish." Requires downstream to have read authority at the upstream resource. Reality is hybrid: upstream **publishes** a release candidate into a stable tier; downstream **chooses when to bind** it into their namespace. The binding contract specifies cadence (auto-follow stable, pin to version, manual promote).
## 3. Governance: binding as a two-sided transaction A downstream binding is not a casual `MOUNT` command. It is a formal event that requires authorization from both sides: - **Upstream mayordomo** confirms: this resource may be exposed to this downstream, under these terms (license, duration, scope, fee-if-any, rate limits, attribution requirements) - **Downstream mayordomo** confirms: our namespace accepts this binding under these conditions (ACL mapping, identity bridging, user-visible branding, obligation to contribute back) - **Both sides emit a ledger entry** reflecting the agreement - **Revocation is equally two-sided**: either party can apoptotically unbind, signaling the other so dependents adapt cleanly This is the acequia precedent literally applied: water rights are granted by community consent, recorded, and revocable on recorded terms. The digital commons inherits the form.
## 4. ACL propagation: three strategies When a user at `gsd.live` reads a resource bound from `geo.camera`, which ACL applies? - **Upstream-ACL enforcement**: the read goes back to redfish, which checks Harvard's user against redfish rules. Usually impractical (identity federation complexity, high coupling). - **Bridge-agent-ACL**: the reverse-proxy agent at the mount point enforces a mapping. Harvard users authenticate via Harvard; the agent applies a role mapping and allows/denies based on the binding contract. This is usually the right answer. - **Downstream-ACL only**: `gsd.live` declares its own rules and upstream trusts the binding contract's promises. Simplest; only appropriate when the binding contract explicitly disclaims upstream liability for downstream misuse. The binding contract records which strategy is in effect and what the role mapping is. The mayordomos on both sides can audit.
## 5. Attribution and credit assignment Every derivative of an upstream resource should trace back to: 1. The immediate upstream source 2. All its upstream sources (recursively) 3. Authors and contributors at each level 4. Any physical or conceptual references (e.g., Hubler for self-assembling-wires work, Murray's law for branching ratios) Mechanisms: - **Provenance sidecar**: each resource carries a `provenance.json` (or equivalent) that lists upstream URIs, authors, and references. Bindings inherit and extend this. - **HTTP `Link` headers**: agent-at-URI responses include `Link: <upstream-uri>; rel=upstream; title="authored by X"` (standard HATEOAS-adjacent convention) - **Directory-listing metadata**: `PROPFIND` on the mount point returns provenance properties - **Chain of custody**: when downstream derives further (GSD student extends geo.camera for a class project), their provenance extends the upstream chain, not replaces it This is the part the modern web mostly botches. NPM tracks direct dependencies but not attribution flow; git tracks commits but not citation chains; Creative Commons specifies license terms but the compliance is manual. An ecology with explicit attribution at the binding layer can sustain this without manual effort.
## 6. Transaction semantics and atomicity A binding is a transaction with: - **Participants** (upstream URI/agents, downstream URI/agents) - **Terms** (license, duration, scope, fees, rate limits, attribution obligations, ACL mapping strategy) - **Approvers** (both mayordomos, signatures verifiable) - **Effective date** and **expiration** (or conditions under which it expires) - **Idempotent ID** for reference in the ledger **Multi-resource bindings** (a whole directory subtree, a suite of related apps) are atomic: either all constituent resources bind, or none. If one fails authorization, the whole binding fails and rolls back. **Rollback is apoptotic**: when a binding is revoked, the apoptotic signal propagates. Dependents observe the signal and adapt (adjust UIs, retire cached tokens, surface a "this is no longer available" state). Not a silent failure to 404.
## 7. Economic ledger An append-only log of binding transactions (and, more broadly, of value flow across the commons). Each entry captures: - **From / to URIs** - **Binding contract** (see §6) - **Authorization chain** (who approved, signatures) - **Timestamps** (created, effective, expired) - **Value flow** (implicit — "this is free" — or explicit — "GSD pays redfish $X/semester for use") - **Contribution credits** (labor, code, physical experimental grounding) - **Dispute history** (if any), with resolution Where the ledger lives: probably per-domain, with bound views across domains so each mayordomo can see the entries relevant to their scope. A mayordomo at redfish sees all outbound bindings from redfish resources; a mayordomo at `gsd.live` sees all inbound bindings into `gsd.live`. Overlap where bindings cross the boundary. Not blockchain. A trusted small-group acequia doesn't need proof-of-work; it needs verifiable signatures from mayordomos and durable append-only storage (which paths-as-event-bus gives you for free). The precedent is centuries of acequia record-keeping: handwritten ledgers that worked because the community was accountable to itself.
## 8. Acequia governance, precisely The water-rights tradition already implemented this pattern: - **Parciantes** have rights to draw water from the ditch (read/access rights on bindings) - **Saca** = annual community labor day to clean the ditch (contribution obligations in the binding contract) - **Mayordomos** allocate flow, record transactions, resolve disputes (two-sided authorization and audit) - **Repartimiento** = rotation schedule for water allocation (rate-limiting and sharing rules) - **Rights and obligations are ledgered** — multi-generational records of who contributed what, whose turn it is, who owes whom Every term in §3–§7 maps onto a centuries-old physical-world precedent. The digital commons is not inventing governance; it's importing a working design.
## 9. Connection to Hubler / self-assembling wires See [self-assembling-wires/ecology.md](self-assembling-wires/ecology.md) for the full frame. In downstream-pattern terms: - **Charge flow through the completed wire IS a transaction.** Value (charge) moves from source (reservoir) through the conduit (wire structure) to the sink (ring electrode). The wire is the binding; without it, no flow. - **The bearings in the successful path are the attributed contributors.** They physically formed the conduit. Ledgering them is noting which actors participated. - **The losing shooters apoptose when the winner completes.** Their material returns to the reservoir and can be recruited by the next structure. Unwon bids apoptose cleanly; their contributors are not obligated further. - **Least-action pathways** set the geometry. The ecology's ledger should converge on least-dissipation structures over time: bindings that impose friction without corresponding value flow should be pruned.
## 10. Decisions still open (carried forward from chat) - **Ledger format and schema**. JSON-LD with verifiable credentials? A custom schema? WebFinger-adjacent? - **Where the ledger lives**. Per-domain with aggregated views, or a central ledger agent accessed via reverse-proxy from each domain? - **Provenance representation**. Sidecar file, Link headers, PROPFIND properties, or all three? - **Push vs pull default** for upstream→downstream propagation - **Billing/compensation mechanism**, if/when applicable — out of band (invoicing), on-ledger (explicit transactions), or integrated with external systems (OpenCollective, Stripe, institutional billing) - **Identity bridging** between domains (Harvard SSO ↔ redfish ↔ ...) - **Migrating existing undocumented deploys** into the ledger retroactively
## When to invoke this pattern - Any deploy that crosses a domain or org boundary - Any derivative work discussion (fork, extension, citation, republication) - Any license or attribution decision - Any question about who can read/write a resource from a bound namespace - Any "should we charge for this?" or "what do we owe upstream?" question - Any recurring flow where downstream should track upstream releases - When someone says the word "downstream" without specifying what layer they mean
## Relationship to adjacent systems - **Not blockchain** (no consensus machinery needed for a trusted small-group acequia) - **Not git subtrees/submodules** (git handles code sync; doesn't model governance/economic overlay) - **Not OpenCollective** (OC handles money; doesn't model resource bindings) - **Not Creative Commons alone** (CC specifies license terms; doesn't record the specific transactional instance) - **Closer to ActivityPub + Creative Commons + OpenCollective + acequia governance, unified via URI bindings and paths-as-event-bus** The pattern exists partly because no existing system covers all six layers in one coherent frame. Building it in the commons means the ecology is self-accounting from day one.