bf9787e56a
Gap analysis of docs/architecture.md against openspec/ and docs/ideas/ found the envisioned-but-uncaptured remainder. This commit captures it: New OpenSpec change (validated): - route-federation — the collaboration half of the federation vision: routes as dereferenceable trails:Route objects, Create/Update fan-out, Invite/Accept collaboration mirroring (arch decision #2), cross-instance Planner edits via HTTP-Signature-requested scoped tokens (decisions #3/#12), mirror sync healing (#16). Depends on social-federation §6 + route-sharing; carries the 2026-06-07 soak lessons as design constraints. New docs/ideas/ explorations: - instance-administration — registration toggle, suspend/ban, federation blocklists, reports (moderation now gates the federated comments idea) - social-interactions — local likes + comments (don't exist even locally; the foundation federated kudos/comments attach to) - activity-participants — group tagging with confirm/decline + federated mentions (the participants jsonb column is an untyped stub) - multi-day-collections — architecture open question #1, directions evaluated architecture.md cleanup: - Mastodon-compat section annotated with shipped/captured state + the live-soak interop lessons (attachment arrays, tombstones, 10s timeout, no backfill) - api.trails.cool removed (contradicted resolved decision #18) - Phase 1 ticked (shipped); Phase 2/3 items annotated with where each is tracked; specs/ → openspec/, activity.* → journal.*, cx21 → cx23 - brouter-web open question marked resolved-in-practice; new section pointing to where the unshipped vision is tracked Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
49 lines
2.2 KiB
Markdown
49 lines
2.2 KiB
Markdown
# Instance administration & moderation
|
|
|
|
Pre-spec exploration. Envisioned in `docs/architecture.md` (§Instance
|
|
Administration) since day one, never spec'd. Now that federation is live
|
|
on staging — a public inbox accepting traffic from arbitrary instances —
|
|
the moderation half has moved from "eventually" to "before the federated
|
|
surface grows."
|
|
|
|
## Scope sketch
|
|
|
|
**Instance settings**
|
|
- Instance name, description, rules page (rendered at `/about`)
|
|
- Open/close registration (env var today at best; should be a runtime
|
|
admin setting)
|
|
- Instance-level contact / operator info (some of this exists for the
|
|
legal pages — consolidate)
|
|
|
|
**User management**
|
|
- Admin role (first user? env-designated? explicit grant)
|
|
- Suspend / unsuspend users (suspended: no login, content hidden,
|
|
federation stops — actor 404s like a private profile)
|
|
- Delete user + content (GDPR path; account-management spec covers
|
|
self-deletion, not admin-initiated)
|
|
|
|
**Federation management**
|
|
- Per-instance blocklist: refuse inbox traffic, drop follows, stop
|
|
deliveries to blocked domains (checked in the inbox rate-limit layer
|
|
we already have — `federationSourceHost` is the natural hook)
|
|
- Per-instance silence (content hidden from shared surfaces but
|
|
follows still work) — maybe later; block first
|
|
- Visibility into federation peers: which instances follow us /
|
|
we deliver to, volumes, error rates (remote_actors table + Fedify
|
|
logs already hold most of this)
|
|
|
|
**Reports & moderation queue**
|
|
- Report content/users (local reports first; ActivityPub `Flag`
|
|
federation later)
|
|
- Simple queue: open → resolved/dismissed, with action taken
|
|
|
|
## Constraints & notes
|
|
|
|
- Mastodon's admin model is the obvious reference; ours can be a tiny
|
|
subset (single-admin instances are the norm for self-hosters).
|
|
- The federated-comments idea (`fediverse-enhancements.md`) explicitly
|
|
depends on at least instance blocks + report handling existing.
|
|
- Suspension must compose with federation the same way profile privacy
|
|
does today: suspended ⇒ actor 404, push delivery suppressed (the
|
|
`social-federation` spec's 9.3 mechanics generalize).
|
|
- Admin surfaces are user-facing strings → i18n from the start (en+de).
|