Whiteboard di assistenza: canali stabili e token ristretti per il realtime

Un canale legato alla board riduce errori e abusi: whiteboard:board_7f3a. Il server sa subito chi parla di cosa, il client non si riconnette alla cieca. La superficie di autorizzazione si restringe, la ripartenza è verificabile¹.

Nomi di canale stabili, ancorati al soggetto, danno contesto all’autorizzazione. Un nome generico non dice nulla, complica ogni riapertura di sessione e non aiuta a capire cosa si è perso. Con un canale per board, la ricostruzione ha un perimetro chiaro: cosa sta sotto la board, chi è abilitato, quali eventi contano¹.

Fidarsi del browser è un errore. Caricare una rotta per agenti non rende il client affidabile. Gli stessi eventi possono arrivare ad agenti, utenti invitati e servizi in background, ma con permessi diversi. I token vanno ristretti per scope e per ruolo, e legati al soggetto del canale. Il nome del canale non basta: non implica da solo il diritto di leggere o pubblicare¹.

Riconciliazione, non best effort. Dopo una disconnessione, client e server devono riallinearsi in modo esplicito. Serve un meccanismo per identificare gli eventi mancanti e per richiederli. È parte del contratto, non un dettaglio di implementazione. Non si deve confondere il livello di fiducia con lo stato applicativo: il primo dice chi può cosa, il secondo qual è l’ultimo evento visto. Lasciare la riconciliazione implicita apre buchi di coerenza e di autorizzazione¹.

Effimero fuori dallo stato. Indicatori di digitazione e ricevute di lettura non sono dati durevoli. Non guidano la riconciliazione e non entrano nello stato della board. Restano segnali transitori utili all’interazione, non chiavi del modello¹.

Separare i piani. La scelta dell’API realtime deve rispettare tre livelli distinti: autenticazione, stato di sottoscrizione ed eventi di dominio. Il client deve sapere se è autenticato, a cosa è iscritto e quali eventi riceve. Ogni livello resta osservabile e separato. Fondere i piani confonde i sintomi: un errore di login sembra un problema di sottoscrizione, un drop di canale sembra un bug di dominio¹.

Contratto stabile, fornitori intercambiabili. Un perimetro REST piano, con canali stabili e token ristretti, consente di fissare l’interfaccia pubblica mentre dietro può cambiare chi fornisce la capability realtime. L’app non si lega a un singolo stack, il codice dell’interfaccia resta fermo. Il contratto non confonde i tre piani e non affida la sicurezza ai nomi di canale¹.

La disciplina tiene insieme i tre capisaldi. Il nome del canale ancora il contesto. I token limitano cosa si può fare. La riconciliazione chiude il ciclo dopo le interruzioni. Ogni punto è esplicito e verificabile. Ogni punto separa il chi può cosa dal come si riallinea lo stato¹.

C’è un ritorno operativo diretto: log e metriche possono riflettere i tre piani separati. Diagnosi e incident response distinguono un problema di autenticazione da un errore di sottoscrizione o da un bug di dominio. Meno falsi positivi, più segnalazioni utili, triage più rapido nelle ore critiche¹.