Summary
flag marks a unit wrong or stale, and lifecycle.status carries active among its values. What the spec does not say is what a flag does to a unit's status — which leaves each implementation to choose, and the tempting choice is to stop serving it.
That choice is a denial-of-knowledge vector: any single member can remove a unit from circulation by objecting to it. It also loses information at exactly the wrong moment, because a contested unit is often the one a reader most needs to see, together with the objection.
Proposal
Add a disputed status, and specify the two rules around it:
- An unresolved flag moves a unit to
disputed. A disputed unit is still served, ranked down, with its flag count exposed alongside its confirmation count.
- Only a human decision — the same gate that governs promotion — moves a unit to a withdrawn state. Flagging never does it alone.
Stated positively: a flag lowers standing and opens a conversation; it does not close one.
Compatibility
This one is not purely additive, and we would rather say so than have it discovered in review. An implementation that does not model disputed will fail to parse a unit carrying it. We think that is the correct failure — an implementation with no concept of dispute should not be told that a disputed unit is active — but it is a real interoperability cost and the decision is the maintainers'.
If it is judged too sharp, an alternative is to leave status alone and add an optional evidence.flags count with the same two rules attached, which keeps existing parsers working.
Reference implementation
colloquy-core — unit::UnitStatus::Disputed, with UnitStatus::is_servable() returning true for it, and the retirement path gated on a signed decision.
Summary
flagmarks a unit wrong or stale, andlifecycle.statuscarriesactiveamong its values. What the spec does not say is what a flag does to a unit's status — which leaves each implementation to choose, and the tempting choice is to stop serving it.That choice is a denial-of-knowledge vector: any single member can remove a unit from circulation by objecting to it. It also loses information at exactly the wrong moment, because a contested unit is often the one a reader most needs to see, together with the objection.
Proposal
Add a
disputedstatus, and specify the two rules around it:disputed. A disputed unit is still served, ranked down, with its flag count exposed alongside its confirmation count.Stated positively: a flag lowers standing and opens a conversation; it does not close one.
Compatibility
This one is not purely additive, and we would rather say so than have it discovered in review. An implementation that does not model
disputedwill fail to parse a unit carrying it. We think that is the correct failure — an implementation with no concept of dispute should not be told that a disputed unit isactive— but it is a real interoperability cost and the decision is the maintainers'.If it is judged too sharp, an alternative is to leave
statusalone and add an optionalevidence.flagscount with the same two rules attached, which keeps existing parsers working.Reference implementation
colloquy-core—unit::UnitStatus::Disputed, withUnitStatus::is_servable()returningtruefor it, and the retirement path gated on a signed decision.