Continuità senza cloud obbligatorio: come CardinalOS progetta il dialogo tra telefono e desktop su protocolli documentati

Novembre 2026 · Redazione CODLAB

Risposta breve: Nel progetto di CardinalOS la continuità tra telefono e computer non richiede alcun account cloud obbligatorio. Il componente in sviluppo «Cardinal Continuità» prevede KDE Connect / GSConnect su Wi-Fi locale per Android e, per iPhone, i profili standard Bluetooth SIG (MAP, HFP), il servizio di notifiche BLE Apple ANCS più CalDAV/CardDAV/IMAP — verificati finora su fixture sintetiche di laboratorio e non ancora collaudati su telefoni commerciali reali.

1. Flussi quotidiani tra telefono e computer quando si cambia sistema

Quando si valuta il passaggio a un desktop Linux europeo, le domande pratiche riguardano spesso non solo il browser o i documenti d’ufficio, ma i gesti quotidiani con lo smartphone: trasferire una foto direttamente sul computer, passare un codice di verifica, consultare con discrezione un avviso urgente durante il lavoro o mantenere allineati contatti e calendario senza esportazioni manuali.

Diversi ecosistemi commerciali chiusi legano questa comodità all’acquisto di telefono e computer dello stesso marchio e all’accesso permanente a un account cloud centrale del produttore. In CardinalOS seguiamo un’impostazione ingegneristica diversa: utilizziamo protocolli locali documentati e standard di sincronizzazione aperti, senza introdurre alcun account di sistema operativo.

2. Android e CardinalOS: collegamento previsto su Wi-Fi locale con KDE Connect / GSConnect

Sul versante Android il progetto libero upstream KDE Connect e la sua integrazione per GNOME Shell GSConnect definiscono un protocollo documentato, cifrato punto-a-punto via TLS sulla rete Wi-Fi locale senza server ponte su Internet.

Per CardinalOS stiamo predisponendo questo flusso nel disegno delle Impostazioni di sistema (la nostra logica di codec e controllo è oggi verificata in laboratorio su controparti sintetiche; le prove reali di abbinamento TLS, rete LAN e radio su telefoni fisici precederanno il rilascio pubblico):

• Abbinamento previsto con certificati sulla rete locale: Il protocollo upstream prevede al primo collegamento sulla stessa rete Wi-Fi lo scambio di una coppia di certificati con impronta di verifica confermata su entrambi i dispositivi, senza login cloud né numero di telefono.
• Invio diretto di foto e documenti via Wi-Fi: La condivisione da Android è progettata per trasferire immagini o documenti sulla rete locale direttamente nella cartella scelta sul computer, senza passaggi su archivi cloud.
• Notifiche, appunti e controllo multimediale: Avvisi in arrivo, condivisione opzionale degli appunti e pausa dei contenuti multimediali durante una chiamata sono progettati con interruttori distinti per singolo dispositivo.

Per questo specifico canale locale KDE Connect i pacchetti restano sulla rete locale tra telefono e workstation; eventuali altre app o servizi cloud installati sullo smartphone seguono le proprie regole di rete.

3. iPhone e Linux: distinguere profili Bluetooth SIG, servizio Apple ANCS e standard Web

Il collegamento tra un iPhone e un desktop non-Apple richiede precisione tecnica. Apple mantiene chiusi servizi come AirDrop e iMessage dietro protocolli proprietari e controlli di piattaforma. Accanto a tali servizi chiusi, iOS espone sia profili standardizzati dal Bluetooth SIG sia un proprio servizio di compatibilità documentato su BLE e protocolli aperti di groupware.

Nel lavoro di laboratorio per «Cardinal Continuità» (documentazione interna di sviluppo, non ancora pubblica) manteniamo questi canali rigorosamente distinti:

1. Servizio BLE Apple ANCS per le notifiche e Bluetooth MAP per i messaggi: Si tratta di due meccanismi diversi. L’Apple Notification Center Service (ANCS) non è uno standard internazionale del Bluetooth SIG, bensì una specifica di compatibilità documentata da Apple su Bluetooth Low Energy (BLE/GATT) che permette, dopo autorizzazione esplicita sull’iPhone, di leggere gli avvisi di sistema (non ogni notifica consente risposta diretta). Separatamente, il profilo standard Bluetooth SIG Message Access Profile (MAP) su OBEX offre accesso in testo semplice ai messaggi supportati — in modo dipendente dal dispositivo e senza sostituire Messaggi di Apple (iMessage).
2. Bluetooth HFP per il controllo chiamate (verifica audio ancora aperta): Per il profilo standard Hands-Free Profile (HFP) il nostro candidato attuale di laboratorio pilota il controllo chiamata tramite interfacce oFono senza riscrivere direttamente PipeWire o WirePlumber; un osservatore attivo del percorso audio e le prove reali in vivavoce su telefoni fisici restano da completare prima del rilascio.
3. CalDAV, CardDAV e IMAP nativi per calendario, contatti e posta: iOS supporta nativamente questi standard aperti nelle impostazioni di sistema. In abbinamento al client in sviluppo Cardinal Mail (basato su Thunderbird) o a qualsiasi server CalDAV/CardDAV/IMAP proprio o europeo scelto dall’utente, agende, rubriche ed e-mail si sincronizzano senza dipendere da iCloud sul PC (percorso verificato finora in CardinalOS su fixture locali DAV e portachiavi in laboratorio).
4. Scambio file su Wi-Fi locale tramite app aperta KDE Connect per iOS: Come documentato dal progetto upstream KDE Connect per iOS, il trasferimento file sulla rete Wi-Fi locale funziona solo mantenendo aperta in primo piano l’app complementare su iPhone; la verifica di interoperabilità con una futura build di CardinalOS su dispositivi reali resta ancora da eseguire.

4. Dichiarare prima i limiti della piattaforma, senza vendere illusioni

Una regola ferma di CodLab è non promettere funzioni il cui controllo tecnico appartiene a un fornitore chiuso. A chi utilizza iPhone indichiamo in anticipo i confini reali:

• Niente AirDrop né iMessage: I servizi proprietari di trasferimento diretto e messaggistica di Apple non sono aperti a sistemi operativi terzi e non vengono imitati in CardinalOS tramite ponti non ufficiali fragili.
• Limiti di esecuzione in background su iOS: iOS sospende rapidamente le app di terze parti in secondo piano. Mentre i servizi Bluetooth di sistema e gli account nativi CalDAV/CardDAV sono gestiti da iOS stesso (con riconnessione e permessi verso CardinalOS ancora da validare su hardware), il trasferimento file Wi-Fi basato su app richiede su iPhone che l’app complementare resti aperta in primo piano.
• Matrice su telefoni commerciali da certificare: Lo stack di continuità è oggi verificato su fixture sintetiche in ambiente di laboratorio isolato; abbinamento radio, audio delle chiamate e matrice di compatibilità su telefoni fisici commerciali e controller Bluetooth restano da dimostrare prima del rilascio pubblico.

5. Architettura di sicurezza: consenso esplicito e nessun relay cloud

Collegare smartphone e computer richiede confini di consenso chiari. Nel progetto di «Cardinal Continuità» valgono tre regole architetturali:

• Opt-in esplicito per dispositivo e per canale: Nel nostro disegno l’abbinamento resta inattivo per impostazione predefinita finché non viene confermato esplicitamente su entrambi gli schermi; le reti non attendibili potranno essere escluse e singoli canali come gli appunti condivisi disattivati separatamente (la verifica di rete e firewall sull’intero sistema rientra nei controlli pre-rilascio).
• Nessun server ponte su Internet per la continuità locale: I canali di collegamento locale non prevedono alcun relay cloud; quando telefono e computer non sono a portata locale, non avviene alcun trasferimento locale.
• Separazione consapevole dalla sincronizzazione remota: Chi desidera sincronizzare posta, calendari o contatti via Internet configura esplicitamente un server basato su standard aperti di propria scelta (server proprio o fornitore europeo DAV/IMAP).

Trovi il quadro completo dei componenti previsti nella pagina prodotto di CardinalOS; su cardinalos.org puoi richiedere il singolo avviso di disponibilità al lancio.