Negentropy: Protocollo di riconciliazione degli insiemi
Negentropy è un protocollo di set reconciliation per individuare quali eventi possiede una parte e quali mancano all’altra, senza reinviare l’intero dataset.
Come funziona
Invece di richiedere ogni evento che corrisponde a un filtro, negentropy confronta due insiemi ordinati e restringe il confronto soltanto agli intervalli che differiscono. Il protocollo scambia riassunti compatti degli intervalli e ricorre a liste esplicite di ID solo dove serve.
- Ordinamento: entrambe le parti ordinano i record per timestamp, poi per ID
- Confronto degli intervalli: scambiano fingerprint per intervalli di record
- Raffinamento: gli intervalli non corrispondenti vengono suddivisi finché gli ID mancanti effettivi non sono chiari
Perché conta
La sincronizzazione Nostr tradizionale usa filtri since basati sui timestamp, che possono perdere eventi a causa di:
- Deriva dell’orologio tra client e relay
- Eventi multipli con timestamp identici
- Eventi che arrivano fuori ordine
Negentropy risolve questi problemi confrontando gli insiemi reali di eventi invece di basarsi sui timestamp.
Uso pratico
- Recupero dei DM: i client possono rilevare e recuperare messaggi diretti mancanti anche con timestamp vecchi
- Sincronizzazione del feed: garantisce una sincronizzazione completa della timeline tra relay
- Sincronizzazione offline: permette di recuperare in modo efficiente dopo periodi di disconnessione
Il dettaglio implementativo utile è che molti client non sostituiscono le normali subscription con negentropy. Lo usano come percorso di riparazione. Damus, per esempio, ha mantenuto il caricamento ordinario dei DM e ha aggiunto negentropy al refresh manuale per recuperare i messaggi che il flusso normale non avrebbe trovato.
Compromessi
Negentropy richiede supporto da entrambe le parti e aggiunge complessità di protocollo oltre all’uso standard di REQ. È più utile quando la correttezza conta più dello sforzo minimo di implementazione.
In ambienti misti, i client hanno comunque bisogno di un fallback graduale perché non tutti i relay supportano il protocollo.
Fonti primarie:
Menzionato in:
Vedi anche: