- Feature Name: `write-tiers` (the bar for a write scales with how
permanent the write is; a tier that costs less may ask less)
- Start Date: 2026-09-12
- Status: Draft
- Depends on: RFC 0004 (capability letters are the native model); RFC
0001 §8 (the OLTP tier is forge-local state, the DAG is truth); RFC
0015 (companions — this RFC amends §"What the parent keeps"); RFC 0008
(roles as the interface over the letters)
- Amends: RFC 0015, which says the companion's name never reaches a
gate. It reaches one here, for writes only.
- Precedent: local tickets already exist as a lower tier
(`docs/local-tickets.md`, `local_ticket`, `ticket.intake`), with the
explicit rationale that an append-only artifact history "has no answer
but 'it is in there now'". This RFC states the rule that tier was an
instance of.
## Summary
quarry stores writes in three places with wildly different costs, and
asks the same price for all of them.
A check-in, a ticket artifact, a wiki page and a forum post in the
repository's own store are permanent, synchronized to every clone, and
unsayable-again. A post in a **companion** store is permanent but
separable — it is not in the store anybody clones for the code. A
**local** ticket is in the forge's database: mutable, deletable, and
carried by nobody.
Those are not the same act, and requiring the same authority for all
three has a visible consequence: a project that wants to take outside
contribution has to choose between letting strangers write its DAG and
letting them do nothing at all.
This RFC states one rule — **the bar may differ per tier, and a tier
that costs less may ask less** — and applies it to the two tiers that
exist. It introduces no new capability letter.
## The tiers, and what a write costs in each
| tier | where | permanence | who carries it |
|---|---|---|---|
| **store** | the repository's own DAG | permanent, unsayable | everyone who clones |
| **companion** | a bound store (RFC 0015) | permanent, separable | whoever clones *that* |
| **local** | forge OLTP | mutable, deletable | nobody |
The ordering is the whole RFC. A store write is the most expensive thing
a stranger can do to a project, because it is the one nobody can undo
and everybody downloads. A companion write is permanent but costs the
code store nothing: it does not enter the repository people clone to
build, it does not grow the artifact history CI walks, and it can be
detached. A local write costs almost nothing and can be discarded.
**So the bar should follow the cost.** Anything else is either too
generous at the top — strangers writing the DAG — or too mean at the
bottom, which is where quarry is today.
## Rule
> An authority that governs writes MAY be set per tier. A lower tier MAY
> hold a lower bar than the tier above it. A lower tier MUST NOT be able
> to raise the bar of the tier above it, and MUST NOT be able to grant
> anything the tier above it denies about *visibility*.
Two halves, and the second is what keeps it safe.
**Writes may relax downward.** A companion may let more people post than
the parent lets push. The local tier may let more people file than the
store lets mint.
**Visibility never relaxes.** Whether a reader may know a repository
exists, and read it, stays the parent's answer in every tier. Otherwise
a private repository's companion becomes a side door: bind a forum,
grant a stranger, and they learn the repository exists and can read
discussion of code they cannot see. RFC 0015 already says the parent
answers "a name they may not see", and that does not change.
The rule is a **union**, like every other authority in quarry (RFC
0004): a tier adds letters, never subtracts them. A relaxed companion
cannot take posting away from somebody the parent already granted it to.
## What changes in RFC 0015
0015 §"What the parent keeps" currently says every forum question — may
this account post, reply, moderate, announce — is answered by the
parent's capability set, and that the companion's name never reaches the
gate. That is amended to split the question:
- **Read and visibility** stay exactly as specified: answered by the
parent, through the parent's name, including its not-found answer.
- **Write letters** — post, reply, attach, and the moderation letters
above them — become the union of the parent's and the companion's own.
So the companion gains what 0015 §"What the companion gets" does not
currently list: **its own grants, for writes only.** It still has no
identity model of its own; accounts remain forge-global, and the
companion's People surface is a section on the parent's settings page
rather than a page on a store that has no page.
This is the point of a companion that 0015 did not state. 0015 justifies
the separation on lease contention and store size — "a busy thread never
waits on a push". The other reason is **policy**: it is a lower burden
to take outside contribution somewhere that is not the store holding the
code, and until a companion can hold a lower bar, that reason is
unavailable.
`forum.bind` therefore becomes an access decision and not only an
operational one, and must say so where it is offered.
## What changes for local tickets
`ticket.intake` (local) and `ticket.new` (store) both gate on `n`, so
the local tier cannot be more relaxed than the store today. The letter
`n` means "file tickets", and fossil had one tier to file into.
`n` becomes the **store** door and only the store door. `ticket.intake`
gates on `r` — read tickets — on the reasoning that quarry's local tier
is deletable and promotable, so the bar for filing into it should be
"you can see the tracker", not "you may write the DAG".
Practically this changes little for existing deployments: fossil's stock
`nobody` category holds `r`, so anonymous intake on a public project
behaves as before. What it makes possible is a repository that takes
tickets from anyone while minting nothing in its store until an admin
promotes one — which is what the local tier was built for and could not
express.
## No new capability letter
The tempting shape is a new letter meaning "may mint a permanent object
in this store", gating `ticket.new`, `forum.post` and wiki creation.
quarry has invented a letter before — `8`, for CI, on the grounds that
fossil has no CI and an unused digit cannot collide with an imported
user table.
It is rejected here. Every existing grant holding `3` or `n` would lose
thread and ticket creation until backfilled, and Reader — which holds
`3` — would silently become reply-only. A migration that changes what
an existing role means is a poor trade for a distinction the tiers
already draw structurally: a write's tier is a property of *where it
lands*, which the forge knows without asking the letters.
## What this does not propose
- A separate identity model for any tier. Accounts stay forge-global.
- Any relaxation of **read** or visibility anywhere.
- A companion for anything but the forum. 0015 defines one feature and
this RFC adds none.
- Moving existing artifacts between tiers. Promotion (local → store)
exists; demotion does not and is not proposed.
- Letting a tier restrict. Every tier adds.
## Consequences to state plainly
**Three routes to one authority.** A person may hold a letter directly,
through a category, or through a lower tier's own grant. Any page that
answers "who may do this" must name the route, not just the result —
the same obligation the union rule already creates elsewhere.
**Binding a forum widens who may post.** That is the feature, and it
must be said at the moment of binding rather than discovered afterwards.
**A relaxed companion is still permanent.** Separable is not deletable:
a companion's history is a DAG like any other, and shunning is the only
removal. The local tier is the one that forgets.
## Open questions
- Should the moderation letters (`4`, `5`, `6`) relax with posting, or
stay the parent's? A companion taking outside contribution is exactly
where moderation matters most, which argues for relaxing them
together — but it also means a companion moderator who holds nothing
on the parent.
- Does a companion's relaxed grant survive unbinding? The store becomes
a repository in its own right, and its grants would become its own.
That is probably correct and should be said.
- Should the wiki be splittable for the same reason? 0015 declined on
the grounds that nobody had asked. The policy argument is new evidence,
not a request.