Revoke an approval

Sometimes you approve something and later decide you shouldn’t have. vidi revoke withdraws a review.

Revoking

Pass either the unit address or the content_id of the review:

$ vidi revoke "crates/vidi-core/src/digest.rs::struct:Blake3Digest"
revoked 28d7043ed80ea10df8a78cd4b6f32f3f as [email protected]
  content_id c6045ac7293ac85f4e5aef54b6d0fbb0 · appended to .vidi/ (bare line, diff-visible)

Two content_ids appear, and they are different things:

Coverage drops immediately:

$ vidi status
NEUTRAL: 0/5356 reviewed · stale 0 · orphans 0 · requirement failures 0 · default shortfalls 0

Nothing is deleted

The original approval is still on disk. Revoking adds a record; it never edits or removes one:

$ wc -l .vidi/reviews.jsonl .vidi/revocations.jsonl
  1 .vidi/reviews.jsonl
  1 .vidi/revocations.jsonl

The vouch is still in reviews.jsonl. The revocation sits in revocations.jsonl, and when the two are resolved the revocation wins, so the unit reads as unreviewed.

The revocation is a much smaller record than a review:

{
  "subject": [{ "name": "revoke" }],
  "predicateType": "https://vidivouch.com/vidi/revoke/v1",
  "predicate": {
    "reason": "...",
    "attesterIdentity": { "kind": "person", "id": "[email protected]" },
    "claimTimestamp": "..."
  }
}

Note the subject name is the reserved word revoke rather than a unit address — the record it cancels is identified by content_id, not by location.

Why append instead of edit

Three reasons, all of which matter for a record you want to trust:

History survives. “This was approved on Tuesday and withdrawn on Thursday” is a fact worth keeping. Deleting the approval would erase it.

Merges cannot conflict. Both files are append-only lists where order does not matter, so merging two branches means keeping every line from both. That is what the merge=union rule added by vidi init does. If revoking edited a line, two people revoking on different branches would collide.

The result cannot depend on merge order. A revocation beats an approval no matter which arrived first, so everyone who merges the same set of records computes the same answer. See Why review files never conflict.

Re-approving

Nothing stops you vouching again after a revocation. It works for a subtler reason than “the newer record wins”.

A revocation targets one specific content_id, and it dominates that record forever — arrival order is irrelevant, and no later record can un-revoke it. But vouching again produces a review with a different content_id, which the revocation simply does not name. The old record stays dead; the new one is live.

This is why revoke-wins can be permanent without ever locking a unit out of review: revocation kills a claim, not an address.

No notary needed

Revocation never requires the hosted notary, even for repos that use signed reviews. Withdrawing a claim you made is always available offline.