Kontinuität ohne Cloud-Zwang: Wie CardinalOS Telefon und Desktop über dokumentierte Protokolle verbindet

Stand November 2026 · Redaktion CODLAB

Kurzantwort: Geräteübergreifendes Arbeiten verlangt im Entwurf von CardinalOS kein herstellergebundenes Cloud-Konto. Die in Entwicklung befindliche Komponente «Cardinal Continuità» sieht für Android das offene Protokoll KDE Connect / GSConnect im lokalen WLAN und für iPhones die Bluetooth-SIG-Profile MAP und HFP, Apples BLE-Benachrichtigungsdienst ANCS sowie CalDAV/CardDAV/IMAP vor — bislang gegen synthetische Labor-Fixtures geprüft, noch nicht auf physischen Serien-Telefonen zertifiziert.

1. Typische Hürden beim Wechsel des Arbeitsplatz-Systems

Wer einen Umstieg auf einen europäischen Linux-Desktop abwägt, denkt im Alltag nicht nur an Webbrowser oder Textverarbeitung, sondern an konkrete Arbeitsabläufe mit dem Smartphone: ein Foto direkt auf den Rechner übertragen, einen Bestätigungscode übergeben, während konzentrierter Arbeit eingehende Hinweise dezent sehen oder Kontakte und Kalender ohne manuelles Exportieren abgleichen.

Manche geschlossene Ökosysteme knüpfen diese Übergabe daran, dass Telefon und Rechner aus derselben Herstellerfamilie stammen und dauerhaft bei einem zentralen Herstellerkonto angemeldet bleiben. Für CardinalOS verfolgen wir einen anderen ingenieurtechnischen Ansatz: Wir stützen uns auf dokumentierte Protokolle im lokalen Funknetz und auf standardisierte Synchronisationsschnittstellen, ohne dass ein zentrales Betriebssystemkonto existiert.

2. Android und CardinalOS: Geplante Direktverbindung mit KDE Connect / GSConnect

Auf Android-Geräten definiert das freie Upstream-Projekt KDE Connect zusammen mit seiner GNOME-Shell-Integration GSConnect ein dokumentiertes, punkt-zu-punkt TLS-verschlüsseltes Protokoll für das lokale WLAN ohne Vermittlungsserver im Internet.

Für CardinalOS bereiten wir diese Kopplung im Entwurf der Systemeinstellungen vor (unsere Codec- und Steuerlogik ist bislang im Labor gegen synthetische Gegenstellen geprüft; TLS-Paarungs-, LAN- und Funkprüfungen mit physischen Telefonen folgen vor dem Release):

• Geplante Zertifikatspaarung im lokalen Netz: Das Upstream-Protokoll sieht beim ersten Koppeln im selben WLAN den Austausch eines Zertifikatspaars mit Prüffingerabdruck und Bestätigung auf beiden Geräten vor — ohne Cloud-Login oder Telefonnummer.
• Direkter Datei- und Fotoversand im WLAN: Aus dem Teilen-Dialog auf Android sollen Bilder oder Dokumente unmittelbar über das lokale Netzwerk in den Zielordner des Rechners übertragen werden, ohne Umweg über einen Cloud-Speicher.
• Mitteilungen, Zwischenablage und Mediensteuerung: Eingehende Hinweise, optionale Zwischenablage-Übergabe und das Pausieren laufender Medienwiedergaben sind im Einstellungsentwurf pro gekoppeltem Gerät einzeln schaltbar.

Für diesen lokalen KDE-Connect-Übertragungsweg selbst verbleiben die Pakete im lokalen Netzwerk zwischen Telefon und Arbeitsplatzrechner; andere auf dem Smartphone installierte Apps oder Clouddienste bleiben davon unberührt.

3. iPhone und Linux: Differenzierter Blick auf Bluetooth-Profile, ANCS und Web-Standards

Schwieriger — und in Produktversprechen oft verkürzt dargestellt — ist das Zusammenspiel eines Nicht-Apple-Desktops mit iOS. Apple hält Dienste wie AirDrop oder iMessage hinter proprietären Protokollen und Plattformprüfungen unter Verschluss. Daneben unterstützt ein iPhone sowohl genormte Bluetooth-SIG-Profile für Freisprech- und Nachrichtenzugriff als auch eigene dokumentierte Kompatibilitätsdienste und offene Groupware-Standards.

In unseren Laboruntersuchungen für «Cardinal Continuità» (interne Entwicklungsdokumentation, noch nicht öffentlich) unterscheiden wir diese Kanäle technisch präzise:

1. Apples BLE-Dienst ANCS für Systemmitteilungen und Bluetooth MAP für Nachrichten: Beide Wege sind technisch getrennt. Der Apple Notification Center Service (ANCS) ist kein internationaler Bluetooth-SIG-Standard, sondern eine von Apple dokumentierte Kompatibilitätsspezifikation über Bluetooth Low Energy (BLE/GATT), über die nach Freigabe am iPhone Systemhinweise gelesen werden können (nicht jede Mitteilung erlaubt eine direkte Antwort). Separat davon dient das standardisierte Bluetooth-SIG-Profil Message Access Profile (MAP) über OBEX dem reinen Textzugriff auf unterstützte Kurzmitteilungen — geräteabhängig und ohne Apple Nachrichten (iMessage) zu ersetzen.
2. Bluetooth HFP für Anrufsteuerung (Audio-Prüfung noch offen): Für das standardisierte Hands-Free Profile (HFP) steuert unser aktueller Laborkandidat Anruffunktionen über oFono-Schnittstellen an, ohne PipeWire oder WirePlumber direkt umzuschreiben; ein aktiver Beobachter für den Audiopfad sowie reale Freisprech-Audiotests mit physischen Telefonen stehen vor dem Release noch aus.
3. Natives CalDAV, CardDAV und IMAP für Kalender, Kontakte und Post: iOS unterstützt diese offenen Synchronisationsstandards nativ in den Systemeinstellungen. Im Zusammenspiel mit dem in Entwicklung befindlichen Cardinal Mail (auf Thunderbird-Basis) oder jedem selbst gewählten eigenen bzw. europäischen CalDAV-/CardDAV-/IMAP-Server lassen sich Termine, Adressbücher und E-Mails ohne iCloud-Pflicht auf dem PC abgleichen (in CardinalOS bislang auf lokalem DAV-/Schlüsselbund-Pfad im Labor geprüft).
4. Lokaler WLAN-Dateiversand über die offene KDE-Connect-iOS-App: Gemäß der offiziellen Dokumentation von KDE Connect für iOS funktioniert der lokale Dateitransfer im selben WLAN nur, solange die Begleit-App auf dem iPhone im Vordergrund geöffnet ist; die Interoperabilitätsprüfung mit einer künftigen CardinalOS-Auslieferung auf realen Geräten steht noch an.

4. Ehrliche Plattformgrenzen statt falscher Versprechen

Ein Grundsatz unserer Arbeit bei CodLab lautet: Wir versprechen keine Funktionen, deren Protokollhoheit bei einem geschlossenen Drittanbieter liegt. Für Nutzerinnen und Nutzer eines iPhones benennen wir die Grenzen vorab:

• Kein AirDrop und kein iMessage: Apples proprietäre Direktübertragung und sein geschlossener Nachrichtendienst stehen Drittbetriebssystemen nicht offen und werden in CardinalOS nicht durch inoffizielle Brücken nachgeahmt.
• Hintergrundgrenzen unter iOS: iOS friert Drittanbieter-Apps im Hintergrund schnell ein. Während System-Bluetooth-Dienste und native CalDAV-/CardDAV-Konten von iOS selbst verwaltet werden (wobei Wiederverbindung und Berechtigungen mit CardinalOS noch auf Hardware zu prüfen sind), verlangt der App-gestützte WLAN-Dateitransfer auf dem iPhone eine geöffnete Begleit-App im Vordergrund.
• Zertifizierung auf Serien-Geräten steht noch aus: Der Kontinuitäts-Stack ist bislang gegen synthetische Fixtures in einer isolierten Laborumgebung geprüft; Funkkopplung, Anruf-Audio und die Kompatibilitätsmatrix über physische Serien-Telefone und Bluetooth-Controller hinweg sind vor einem öffentlichen Release noch nachzuweisen.

5. Sicherheitsentwurf: Ausdrückliche Kopplung und keine Cloud-Relays

Kontinuitätsfunktionen verbinden zwei persönliche Geräte. Im Sicherheitsentwurf von «Cardinal Continuità» gelten dafür drei Architekturregeln:

• Ausdrückliches Opt-in pro Gerät und Kanal: Eine Kopplung ist im Entwurf standardmäßig inaktiv, bis sie auf beiden Bildschirmen ausdrücklich bestätigt wird; nicht vertrauenswürdige Netze sollen sich ausnehmen und einzelne Kanäle wie die Zwischenablage separat abschalten lassen (die Netz- und Firewall-Prüfung am Gesamtsystem ist Teil der Vorab-Verifikation).
• Keine Internet-Vermittlungsserver für lokale Kontinuität: Die lokalen Kopplungswege sehen keinen Cloud-Relay vor; sind Telefon und Rechner außer Reichweite, findet keine lokale Übertragung statt.
• Bewusste Trennung zur Internet-Synchronisation: Wer E-Mails, Kalender oder Kontakte über das Internet synchronisieren möchte, richtet dafür explizit einen selbst gewählten Standard-Endpunkt (eigener Server oder europäischer DAV-/IMAP-Anbieter) ein.

Einen Gesamtüberblick über alle geplanten Bausteine finden Sie auf der CardinalOS-Produktseite; für die einmalige Mitteilung zum Start können Sie sich auf cardinalos.org vormerken.