RFC 0021 — Fediverse UI: admin foundations (settings + trust list)

Auteur : EBO (rustwarden)
Date : 2026-05-10
Statut : Accepted (auto-revue mainteneur unique 2026-05-10, score 26/35)
Apps consommatrices concernées : toute app utilisant rustwarden-ui qui veut piloter la fédération via UI HTML.
Plan associé : Plan UI HTML Fediverse §7 Slice A.
Dépendances : RFC 0001 (FediverseConfig), RFC 0004 (FediverseTrustService), constitution Rustwarden (HTMX/Alpine/CSRF/i18n).

Summary

Livrer les deux écrans admin foundationnels qui débloquent toute la suite de l'UI fediverse :

/admin/fediverse/settings — toggle runtime fediverse_enabled, sélecteurs trust_mode (allowlist / open_with_blocklist), interop_scope (rustwarden_only / rustwarden_plus_universal_read / open), checkbox authorized_fetch.
/admin/fediverse/trust_list — table des domaines avec form d'ajout (handle + raison) et bouton suppression confirmé. Affiche la allowlist ou la blocklist selon trust_mode.

Cette RFC livre aussi 3 partials Askama partagés réutilisés par les Slices B et C : _modal_confirm.html, _toast.html, _empty_state.html.

Motivation

Sans ces deux écrans, la fédération est pilotée uniquement par SQL direct ou variables d'environnement. Aucun admin non-technique ne peut activer/désactiver la fonctionnalité ni gérer la liste de confiance — le master plan §10 Phase 5 identifie cela comme un blocant adoption.

Non-goals

Pas de gestion fine par scope (trust_scope per-domain) — différé à une RFC future si la demande émerge.
Pas de bulk-import de domaines — un par un suffit pour le MVP.
Pas d'auto-discovery d'instances Mastodon — l'admin sait quoi ajouter.
Pas de page mobile dédiée — DaisyUI responsive suffit (denses : pas de problème ≤ 50 rows).

API proposée

Routes UI HTML (rustwarden-ui)

Méthode	Path	Handler	Auth
GET	`/admin/fediverse/settings`	`admin_fediverse::get_settings`	admin
POST	`/admin/fediverse/settings`	`admin_fediverse::update_settings`	admin + CSRF
GET	`/admin/fediverse/trust_list`	`admin_fediverse::get_trust_list`	admin
POST	`/admin/fediverse/trust_list/add`	`admin_fediverse::add_trust_entry`	admin + CSRF
POST	`/admin/fediverse/trust_list/{id}/delete`	`admin_fediverse::delete_trust_entry`	admin + CSRF

Si fediverse_enabled=false au runtime : toutes ces routes sauf get_settings/update_settings retournent 404 (Plan UI §3 P9). La page settings reste accessible pour permettre la (ré)activation.

Templates Askama (nouveaux)

crates/rustwarden-ui/templates/admin/fediverse/
├── settings.html            # Slice A — toggle + sélecteurs
├── trust_list.html          # Slice A — table + form
└── _empty_state.html        # partial réutilisable Slices B/C
crates/rustwarden-ui/templates/components/fediverse/
├── _modal_confirm.html      # partial confirmation destructive
└── _toast.html              # partial feedback HTMX (oob)

Handlers (nouveau fichier)

crates/rustwarden-ui/src/handlers/admin_fediverse.rs — 5 handlers Axum.

i18n (nouveau)

locales/{fr,en,de,es}/fediverse.yaml — clés :

settings.* (toggle, selectors, save button, save toast)
trust.* (add, delete, confirm, empty state)
common.* (cancel, confirm, error_500)

Compatibilité

Aucun impact sur les apps consommatrices qui n'utilisent pas rustwarden-ui. Les routes API JSON parallèles existent déjà (RFC 0004 FediverseTrustService) et restent inchangées.

Les templates s'ajoutent ; aucun template existant n'est modifié.

Alternatives

Ne rien faire — rejeté : adoption bloquée pour les admins non-SQL.
Tout sur un seul écran (settings + trust_list fusionnés) — rejeté : viole P1 (une action primaire par écran), 4 sélecteurs + table + 2 forms = surcharge.
Séparer en 2 RFCs (settings d'abord, trust_list après) — rejeté : trust_list est inutilisable sans settings et inversement (le trust_mode détermine quelle table afficher) ; les coupler force la cohérence.
SPA Alpine au lieu de HTMX — rejeté : viole la convention Rustwarden HTMX-first.

Testing plan

Test	Type
`get_settings` non-admin → 403	handler
`update_settings` toggle off → DB row mise à jour	handler + mock DB
`update_settings` invalid trust_mode → 400 + form rendu	handler
`get_trust_list` mode allowlist → table allowlist	handler
`get_trust_list` mode blocklist → table blocklist	handler
`add_trust_entry` doublon → 409 + toast erreur	handler
`delete_trust_entry` not found → 404	handler
`fediverse_enabled=false` : `/trust_list` → 404	route guard
Tabbing complet sur chaque page	manuel
Lighthouse a11y ≥ 95	manuel

Les handlers utilisent MockDatabase ; aucun PostgreSQL nécessaire.

Migration guide

Aucune migration SQL. Les apps qui utilisent rustwarden-ui doivent :

Activer la feature experimental-fediverse sur les deux crates.
Monter le router via rustwarden_ui::routes::router_with_fediverse(...) (helper ajouté dans cette RFC).
Fournir le pack i18n fediverse.yaml (livré dans locales/).

Open questions

Q1 : faut-il un toast de confirmation après chaque toggle, ou un banner persistant « Fédération activée » en haut des pages fediverse ? Réponse retenue : toast (cohérent avec le reste).

Score (26/35)

Critère	Note	Détail
Généralité	4/5	Réutilisable par toute app `rustwarden-ui` ; les partials servent Slices B/C.
Stabilité API	5/5	Pas de breaking change ; pures additions.
Performance	4/5	Templates Askama compilés ; pas de N+1.
Sécurité	3/5	CSRF + admin_required couvrent les bases ; pas d'audit dédié.
Complexité	3/5	5 handlers + 5 templates + i18n × 4 = ~600 LoC.
Maintenance	4/5	Patterns existants Rustwarden réutilisés.
Documentation	3/5	Cette RFC + rustdoc handlers ; pas de guide opérateur dédié.

eric / rustwarden