Commune

Bloc: Anarchist Governance CLI

3 min read

A Forgejo coordination tool that encodes anarchist organizing principles as executable commands. Demonstrates how abstract values translate into concrete design choices.

The Pattern: Principles as Code

When building coordination tools for non-hierarchical groups, governance principles become command structures. Rather than documenting “how we do consent-based decision-making,” encode the rules as transparent, auditable operations.

bloc implements this for the commune’s Forgejo-based governance.

Design Patterns

# Automate consent calculation
bloc governance check-threshold --pr 42
 
# Detect reviews on old commits
bloc governance detect-stale --pr 42
 
# Prevent self-approval (encoded as constraint)
bloc governance prevent-self-review --pr 42

Rather than requiring a coordinator to manually verify these patterns, the tool makes governance rules executable by anyone.

Transparency Without Surveillance

# Self-accountability
bloc audit my-approvals --since 2026-02-01
 
# Personal tracking
bloc audit my-activity --repo commune/library
 
# Community health check
bloc audit who-active --days 30

Notice: anyone can query their own activity or aggregate community patterns, but the tool doesn’t enable tracking specific others without consent. Transparency serves accountability, not control.

Escalation Without Hierarchy

# Identify expertise by contribution history
bloc delegate find-expert --topic "docker security"
 
# Request review with justification
bloc delegate escalate 42 --to @security-interested \
  --reason "needs review of SSH hardening changes"

Authority emerges from demonstrated competence and explicit consent, not position. The tool surfaces expertise without creating a management layer.

Reducing Coordination Overhead

# Aggregate meeting responses
bloc meeting synthesize 15 --guide-moderator
 
# Batch operations reduce toil
bloc batch review --where mentioned --repo commune/skills

Automation serves to reduce toil, not to replace deliberation. Consent remains human; coordination can be automated.

Architectural Choices

The tool’s design encodes values at the infrastructure level:

ChoiceValue Encoded
Python + typer + richIteration speed over performance — tools should be modifiable by their users
Repo inference from git contextNo global config, no central registry — topologically distributed (like gh CLI)
JSON output mode (--json)Scriptable by anyone — extensibility through composition
Auth chain: env → rbw → ForgejoCredentials controlled locally — self-sovereignty over secrets
Explicit merge requirementEven with all approvals, no auto-merge — safety over convenience

These aren’t neutral technical choices. They’re how “distributed authority” and “consent over automation” manifest in code.

The Design Process

  1. Identify a coordination burden — checking PR status, finding reviewers, calculating thresholds
  2. Ask: Does automating this centralize or distribute power?
  3. If it distributes: encode the governance rule as a transparent, auditable command
  4. If it centralizes: redesign to surface information, not make decisions
  5. Test: “Could this tool bypass consent or hide information?” If yes, redesign

Tools shape behavior. A CLI that makes unilateral merges easy will produce unilateral merges. A CLI that makes consent-checking easy will produce better consent processes.

Beyond Bloc

This pattern applies to any coordination infrastructure:

  • CI systems that enforce branch protection — consent becomes automatic
  • Webhook routers requiring explicit subscriptions — no silent surveillance
  • Meeting bots that synthesize but never vote — facilitation without authority
  • Label systems anyone can query but only owners modify — transparency with boundaries

When you build for non-hierarchical groups, your design choices are political choices. The question isn’t “what features should this have?” but “what behaviors will this make easy, and what will it make hard?”

See Also

Graph View