Multi-writer ACL (Phase 1.1)

[sanity]

Problem

Phase 1.0 is single-writer (only the repo owner can sign anything). Phase 1.1 introduces a real ACL so collaborators can push directly to the canonical repo without each running their own clone-and-pull dance.

What needs to happen

The data structures (AclState, WriterGrant, RefEntry.auth_epoch, etc.) are already in place in freenet-git-types — they're carried in the schema with epoch=0 and no grants. Phase 1.1:

1. Update freenet-git-types::validate_state to enforce the epoch model:
   • Require grants[entry.updater] exists.
   • Require grant.granted_at_epoch <= entry.auth_epoch.
   • Require grant.revoked_at_epoch.is_none() OR entry.auth_epoch < revoked_at_epoch.unwrap().
2. Add freenet-git CLI commands:
   • add-writer — owner signs an updated AclState.
   • remove-writer — owner signs an AclState with revoked_at_epoch set, AND owner re-signs every RefEntry currently authored by the revoked writer (per the spec's "Pre-revoke replay window" mitigation).

Schema compatibility

Phase 1.0 schema already includes the ACL fields, so Phase 1.1's contract WASM upgrade does NOT change the schema layout — only the validate_state logic. Existing Phase 1.0 repos are forward-compatible: owner-only validates correctly under the Phase 1.1 contract because the owner is implicitly authorized regardless of grants.

But the repo contract WASM hash WILL change, which changes the contract key. This is a migration: announce the upgrade pointer in the old contract's RepoState.upgrade field, point at the new key. River has prior art for permissionless migration.

Tests

• Grant W, push as W, revoke W, assert old W-signed entries still validate while new W-signed entries (claiming the current epoch) are rejected.
• Property test: owner re-signs every refs[r] where updater == revoked_writer at revocation time, assert no surviving W-signed entries point at refs (the operational mitigation).

[AI-assisted - Claude]

[sanity]

Status check 2026-05-01: still relevant and unchanged in scope.

One correction to the original body: it says 'the repo contract WASM hash WILL change, which changes the contract key. This is a migration: announce the upgrade pointer in the old contract's RepoState.upgrade field, point at the new key.'

That was true for the original design. Since 0.1.0 we switched to delta-style prefix-based URLs (key = BLAKE3(BLAKE3(WASM) || serialize({prefix}))), so:

• The user-facing URL stays the same across WASM upgrades.
• The Freenet contract key changes because the WASM hash changed.
• Phase 1.0 → 1.1 migration is via the legacy_contracts.toml machinery in freenet/freenet-git#21 (probe legacy contract keys from same prefix on GET-not-found).
• The RepoState.upgrade field is still useful for forking a repo to a totally new identity, but it's no longer the migration mechanism for WASM-only upgrades.

Implementation sequencing: probably better to land #21 first (so 1.0 users have a smooth path to 1.1) and then 1.1 (this issue).

[AI-assisted - Claude]