Le notifiche push consentono la ricezione di eventi asincroni su dispositivi mobili, quali l’arrivo di nuovi messaggi, aggiornamenti di stato o avvisi di sistema, anche quando l’applicazione non é aperta.

A differenza delle richieste effettuate su iniziativa del client, le notifiche push consentono al server di inviare informazioni in modo proattivo, riducendo la latenza percepita dall’utente e limitando il numero di connessioni ridondanti verso i servizi remoti.

Modelli tradizionali

Periodic polling

Nel modello periodic polling, il client apre a intervalli regolari una connessione verso il server per verificare la presenza di nuovi dati. Un tipico scenario prevede un client email che interroga il server ogni 15 minuti, chiedendo se siano presenti nuovi messaggi.

Il periodic polling presenta alcune criticità rilevanti:

  • Latenza intrinseca, poiché la ricezione delle informazioni dipende dalla frequenza di polling
  • Elevato numero di connessioni inutili, in quanto la maggior parte delle richieste non produce nuovi dati

Questo modello risulta pertanto inefficiente, sia dal punto di vista del consumo energetico sia in termini di utilizzo della rete.

Long polling

Un’alternativa al periodic polling consiste nel mantenere una connessione persistente e sempre attiva tra client e server, attraverso la quale il server può inviare immediatamente le notifiche non appena disponibili.

Nella pratica, la gestione di connessioni persistenti richiede:

  • Invio periodico di ping per mantenere aperta la sessione
  • Ristabilimento della connessione in seguito a cambi di rete (es. passaggio da Wi‑Fi a rete cellulare) o a disconnessioni temporanee

Sebbene sia tecnicamente possibile per ogni applicazione connettersi al proprio server e ricevere notifiche direttamente, ci sono diversi motivi per cui questo approccio potrebbe non essere pratico o efficace. Per ridurre il carico di risorse, il sistema operativo tenta di sospendere le applicazioni che non sono attivamente in uso. Tuttavia, se ogni app mantiene attivamente una connessione al server, l’OS non può sospenderle. Molte app che pingano i propri server a intervalli variabili possono impedire al dispositivo di entrare in sospensione, causando un consumo più rapido della batteria.

Conferire a un’app speciale la possibilità di stabilire connessioni prioritarie riduce questi problemi e consente all’OS di sospendere efficientemente le altre applicazioni e di andare in standby, risparmiando risorse.

FCM come infrastruttura centralizzata

fcm

Su Android, la soluzione ampiamente adottata per la gestione centralizzata delle notifiche push è Firebase Cloud Messaging (FCM), integrata nei Google Play Services. Questi mantengono una connessione persistente con i server Google, fungendo da intermediari tra le applicazioni installate sul dispositivo e i servizi remoti che desiderano inviare notifiche.

In questo modo, molte applicazioni possono delegare la gestione delle notifiche a una sola applicazione di sistema, riducendo la necessità di mantenere connessioni proprie verso i rispettivi server.

Limiti di un modello centralizzato

Nonostante l’efficienza tecnica, questo modello presenta alcune limitazioni dal punto di vista della libertà dell’utente e della trasparenza:

  • Le notifiche continuano a transitare attraverso i server di Google anche su dispositivi che utilizzano stack alternativi, come microg, per rimuovere altre componenti proprietarie
  • Il sistema operativo può imporre restrizioni aggiuntive alle applicazioni che desiderano mantenere una connessione persistente diretta verso i propri server, richiedendo spesso autorizzazioni specifiche o esenzioni dalle ottimizzazioni della batteria
  • L’architettura è di fatto centralizzata, non consentendo la scelta del fornitore all’utente

Questi aspetti hanno motivato lo sviluppo di soluzioni alternative libere e decentralizzate.

Obiettivi e principi di UnifiedPush

Le notifiche push sono essenziali per l’esperienza mobile moderna perché permettono alle app di comunicare con gli utenti in tempo reale, anche quando non sono attivamente in uso. La libreria proprietaria FCM non può essere inclusa nelle app di F‑Droid e dipende dalla presenza dei servizi Google. Di conseguenza, era comune vedere le applicazioni FOSS adottare una connessione diretta persistente tra l’applicazione e il server, consumando moltissima batteria.

UnifiedPush è un framework open-source che garantisce la consegna di notifiche push in modo decentralizzato, con l’obiettivo di svincolare gli utenti e gli sviluppatori dall’obbligo di utilizzare piattaforme centralizzate proprietarie.

Le applicazioni che supportano UnifiedPush possono ricevere notifiche tramite un’app dedicata che mantiene una singola connessione al server per ricevere tutte le notifiche. Chiamiamo questa applicazione un distributore (distributor), poiché distribuisce le notifiche push alle altre app sul dispositivo.

UnifiedPush offre una serie di vantaggi rispetto alle soluzioni centralizzate e proprietarie:

  • Possibilità di scegliere o self-hostare il server push, migliorando il controllo dei propri dati
  • Riduzione della dipendenza da un singolo fornitore
  • Allineamento con i principi del software libero e della decentralizzazione
  • Facilità di integrazione grazie a uso di standard aperti lato server, come WebPush

Architettura

L’architettura si basa su tre componenti principali: applicazione, distributor e server push.

  • Applicazione: software che necessita di ricevere notifiche push (ad esempio un client Mastodon o un client email)
  • Distributor: componente installato sul dispositivo, incaricato di mantenere la connessione verso il server push e di consegnare i messaggi alle applicazioni
  • Server push: servizio remoto che riceve le notifiche dai server delle applicazioni (ad esempio istanze Mastodon, server mail, ecc.) e le inoltra al distributor

unifiedpush

Nel caso in cui il server dell’applicazione non supporti nativamente UnifiedPush, un Push Gateway può convertire le notifiche specifiche dell’applicazione, in modo da renderle compatibili con UnifiedPush. Questo é quello che accade con Mollysocket, che consente di ricevere notifiche di Signal su un applicazione compatibile con UnifiedPush, come Molly.

Flusso

Registrazione

Il processo può essere descritto come segue:

  1. L’applicazione invia al distributor una richiesta di registrazione
  2. Il distributor contatta il server push per generare un nuovo endpoint associato a tale registrazione
  3. Il server push restituisce l’endpoint al distributor
  4. Il distributor invia all’applicazione un messaggio contenente l’endpoint
  5. L’applicazione trasmette l’endpoint al proprio server di backend, che lo utilizza per inviare future notifiche push

Consegna delle notifiche

Una volta completata la registrazione, la consegna delle notifiche segue il flusso:

  1. Il server dell’applicazione (es. mastodon.social o social.novemila.org) invia un messaggio WebPush all’endpoint fornito, indirizzandolo al server push
  2. Il server push riceve il messaggio
  3. Il distributor, in ascolto sul canale con il server push, riceve la notifica e la inoltra verso l’applicazione
  4. L’applicazione riceve la notifica e ne gestisce il contenuto

Questa catena consente di mantenere una sola connessione persistente per molteplici applicazioni, analogamente al modello FCM, ma senza ricorrere a un’infrastruttura centralizzata proprietaria.

unifiedpush-flow

UnifiedPush richiede la crittografia end-to-end: le notifiche sono crittografate dai server delle applicazioni e decrittografate dalla applicazione mobile.

Implementazioni

Diversi progetti FOSS implementano il ruolo di distributor e/o server push, con livelli di complessità e requisiti di deployment differenti.

Esempi di distributor/server push sono:

  • Sunup: soluzione pensata per un’adozione rapida e una configurazione semplice
  • ntfy.sh: server push semplice da self-hostare
  • NextPush: componente che si integra con Nextcloud
  • Soluzioni basate su XMPP, come l’uso di Conversations, per utenti che adottano XMPP come piattaforma di messaggistica

Sul lato delle applicazioni client, molte app Android open source hanno integrato UnifiedPush, tra cui: Moshidon, Nagram (un client alternativo per Telegram), IronFox, Molly (client compatibile con Signal) e molte altre.

L’elenco aggiornato delle applicazioni compatibili è disponibile sul sito ufficiale del progetto.

unifiedpush-apps

Il modo più semplice per configurare UnifiedPush con un’app Android che lo supporta è:

  • Installare Sunup, che è il distributor, utilizzando il server push di default, quello di Mozilla
  • In alternativa, installare come distributor ntfy, che utilizza di default il server push https://ntfy.sh/
  • Aprirla e disabilitare l’ottimizzazione della batteria
  • Attivare UnifiedPush nell’applicazione; dovrebbe ora rilevare automaticamente Sunup

Quando sono disponibili più distributori sullo stesso device (come ntfy, NextPush, Sunup), é possibile scegliere tra loro. Quando ce n’è solo uno, viene selezionato automaticamente.

choose-distributor

Nel caso di Signal, seguire la nostra guida.

Riferimenti