5 Jahre UnifiedPush

Es ist bereits 5 Jahre her, seit UnifiedPush gestartet ist! Das bedeutet auch, dass ich seit 5 Jahren keine Play Services, weder die offizielle noch die microG-Neuimplementierung, mehr habe. Es ist ein guter Zeitpunkt, um eine Zusammenfassung zu erstellen und darüber nachzudenken, was UnifiedPush in 5 Jahren sein kann.
Eine Übersetzung von s3nnet

Es stellte sich heraus, dass ich mich nicht mehr genau daran erinnern kann, wie alles angefangen hat. Ich musste einige historische Pull-Anfragen und Chats lesen.

Warum brauche ich Push-Benachrichtigungen?

Ich glaube, ich habe mein erstes alternatives ROM, LineageOS, etwa 2013 installiert und bin seitdem nie wieder zu Standard-ROMs zurückgekehrt. Zu dieser Zeit interessierten mich die Apps, die ich installierte, nicht wirklich, es ging mir hauptsächlich darum, die Kontrolle über meine Geräte zu übernehmen und die Bloatware loszuwerden.

Ich wusste, dass ich die Play Services oder eine Neuimplementierung benötigte, damit einige Anwendungen ordnungsgemäß funktionierten, und ich wusste auch ungefähr, warum. Jedes Mal, wenn ich mein Telefon aktualisierte, musste ich also in die benutzerdefinierte Wiederherstellung (TWRP) booten, um eine ZIP-Datei zu flashen und microG zu erhalten. Das war, nun ja ... nicht gerade die beste Benutzererfahrung.

Dann habe ich versucht, ohne die Play Services auszukommen, aber das war noch schlimmer: Nachrichten waren unzuverlässig, der Akku entlud sich schnell und es gab viele Vordergrundbenachrichtigungen, die, wie ich verstanden habe, erforderlich waren, um einen Dienst am Laufen zu halten.

Also entschied ich mich für eine Abspaltung von LineageOS, die standardmäßig microG enthält und vom microG-Team vertrieben wird: LineageOS for microG.

Auch nach der Umstellung auf dieses neue System war die Erfahrung fast dieselbe. Warum? Weil die meisten meiner Apps von F-Droid stammten. Push-Benachrichtigungen mit Google (über microG) erfordern die Verwendung einer proprietären Bibliothek *, die mit Telemetrie ausgestattet ist, sofern diese nicht ausdrücklich ausgeschlossen wird. F-Droid lehnt diese Bibliothek ab, was angesichts ihres Ziels, freie Software zu fördern, fair ist.

* Es ist tatsächlich möglich, FCM (Google-Benachrichtigungen) ohne Google-Bibliothek zu verwenden, aber das wusste ich zu diesem Zeitpunkt noch nicht. Siehe dazu den Blogbeitrag von UnifiedPush über Push-Benachrichtigungen für dezentrale Anwendungen oder das Problem von Molly bezüglich der FOSS-FCM-Implementierung.

Gotify (2020)

Wir schreiben das Jahr 2020, und ich möchte endlich herausfinden, warum ich microG nicht mit Fedilab und Element von F-Droid verwenden kann und ob wir microG durch eine andere Benachrichtigungs-App ersetzen können.

Es stellt sich heraus, dass F-Droid unter anderem die Benachrichtigungsanwendung Gotify vertreibt. Diese kann zwar keine Benachrichtigungen an andere Apps weiterleiten, aber es gibt ein offenes Ticket für diese Funktion, und jmattheis, der Entwickler, scheint offen für diese Idee zu sein.

Ich habe mich zu diesem Zeitpunkt noch nicht mit Android-Entwicklung beschäftigt, aber ich habe versucht, etwas zu hacken. Glücklicherweise hat mir die Überprüfung durch jmattheis sehr dabei geholfen, die Dinge weniger hacky zu gestalten. So entstand gotify-connector.

Aus der Pull-Request-Historie geht hervor, dass „connector” von jmattheis stammt, zu dem ich später „distributor” hinzugefügt habe.

Derzeit hat die Funktion das Interesse einiger Personen geweckt, darunter sorunome, karmanyaahm und sparchatus. Sorunome, Mitwirkender bei FluffyChat, sagte mir, dass die Funktion für die Leute im OpenPush Matrix-Raum interessant sein könnte.

Erste UnifiedPush-Version (2020)

Ende 2020, als ich mir einige P2P-Projekte ansah, dachte ich, es wäre cool, auch eine P2P-basierte Lösung zu haben. So kamen die Fragen nach der Bindung an ein Ökosystem einer reinen Gotify-Lösung, der Akzeptanz und der Fragmentierung auf. Wenn wir mehrere Anwendungen haben, die Push-Benachrichtigungen bereitstellen können, sollten wir eine Bibliothek haben, die mit allen kompatibel ist. Wenn eine neue Anwendung veröffentlicht wird, die Push-Benachrichtigungen bereitstellt, wären alle bestehenden Anwendungen, die diese Funktion unterstützen, direkt kompatibel. Um diesen Weg einzuschlagen, mussten wir zunächst festlegen, wie das Ganze funktionieren sollte.

Ich teilte die Idee im OpenPush-Raum mit, und sie weckte das Interesse einer bestimmten Person, sparchatus, die mir beim Verfassen der Spezifikationen half. Wir diskutierten viele Randfälle, um zu sehen, wie die Dinge aussehen könnten.

Ich habe eine erste Version der Spezifikationen, eine Bibliothek und einen Fork von gotify veröffentlicht, bis die Unterstützung zusammengeführt wurde *.

Sorunome war daran interessiert, die Unterstützung in Fluffychat zu implementieren. Dazu war eine Flutter-Bibliothek erforderlich, und karmanyaahm schrieb eine Bibliothek, die die bereits veröffentlichte Bibliothek auf das Framework portierte. Wir brauchten auch etwas, um das Matrix-Push-Protokoll zu übersetzen und den gotify-Server kompatibel zu machen: karmanyaahm schrieb dafür common-proxies.

* Was tatsächlich nie passiert ist 🤷

FluffyChat, Fedilab und mehr (2021)

Anfang 2021 unterstützte FluffyChat UnifiedPush. Bald darauf kam auch Fedilab hinzu, da der Entwickler Thomas direktes Interesse daran hatte.

Der Start mit diesen beiden Anwendungen war eine Chance für das Projekt: Wir hatten Unterstützung für Matrix und viele andere Chats, die Matrix-Brücken verwenden, sowie für das Fediverse. Damit waren genug Anwendungen für einige FOSS-Enthusiasten abgedeckt. Rückblickend hätte UnifiedPush ohne diese beiden Anwendungen vielleicht nie begonnen.

Danach begannen einige Anwendungen mit der Implementierung der Funktion, darunter eine Tox-Anwendung oder FMD, eine FOSS-Lösung zum Auffinden Ihres Geräts.

Mitte 2021 implementierte ich die UnifiedPush-Unterstützung für Element, die bald von SchildiChat, einem Fork, übernommen wurde. Ich denke, die Erfahrungen mit SchildiChat haben dazu beigetragen, dass es Mitte 2022 in Element integriert wurde.

UnifiedPush für Linux (Mitte 2021)

In diesem Moment kam vurpo in den UnifiedPush-Matrix-Raum, um über Push-Benachrichtigungen für Linux-Geräte zu sprechen. Also haben wir UnifiedPush für Linux entwickelt, indem wir die Spezifikationen für Android auf D-Bus IPC gespiegelt haben.

ntfy, NextPush (2021)

Im Jahr 2021 tauchte ein neues Projekt im Internet auf: ntfy. Ein Projekt wie Gotify, das ohne Konto und mit einem öffentlichen Server funktioniert. Die App ist extrem einfach zu bedienen, da Sie nichts einrichten müssen. Und der Entwickler, binwiederhier, war direkt daran interessiert, UnifiedPush zu unterstützen, um ntfy zu einem Distributor zu machen.

Die Fusion Anfang 2022 war ein wichtiger Schritt für UnifiedPush: Wir haben nun einen Distributor, den wir standardmäßig empfehlen können.

Zur gleichen Zeit habe ich auch NextPush implementiert, wodurch es einfach möglich ist, einen Push-Server selbst zu hosten, wenn man bereits einen Nextcloud-Server hostet.

Gleichzeitig teilte uns der Gotify-Entwickler mit, dass er es letztendlich vorzieht, die Unterstützung nicht zusammenzuführen, da er sie nicht nutzt und es vorzieht, seinem Projekt keinen zusätzlichen Wartungsaufwand hinzuzufügen, was vollkommen verständlich ist. Angesichts dieser neuen Position, der offiziellen Unterstützung von UnifiedPush durch ntfy und der neuen NextPush-App habe ich es vorgezogen, auch die Gotify-Forks einzustellen.

KUnifiedPush (Mitte 2022)

Mitte 2022 veröffentlichte das KDE Team, insbesondere vkrause, KUnifiedPush: einen Distributor für Linux, der mit verschiedenen Push-Servern wie ntfy oder NextPush kompatibel ist. Bis dahin hatten wir nur POC-Implementierungen von Distributoren für Linux. KUnifiedPush bietet auch Bibliotheken für KDE-Anwendungen.

Dadurch konnten Linux-Anwendungen endlich das Protokoll unterstützen.

Vollzeit bei UnifiedPush (2024–2025)

Ende 2023 haben wir mehr als 20 Anwendungen, die UnifiedPush unterstützen, und einen weiteren Distributor: Conversations. Element ist derzeit wahrscheinlich derjenige mit der größten Nutzerbasis. Jemand hat mir geraten, mich bei NLnet um eine Förderung zu bewerben, da dies die Entwicklung des Projekts vorantreiben würde.

Während des Antragsverfahrens bei NLnet wandte sich COVESA an mich, weil sie das Projekt unterstützen wollten, aber einige Funktionen benötigten, die noch nicht vorhanden waren, um einen robusteren Autorisierungsmechanismus zu erhalten und Registrierungsspamming zu vermeiden.

UnifiedPush war schon immer mit Web-Push kompatibel (RFC8030 und RFC8291, aber RFC8292, auch bekannt als VAPID, war es nicht). Die Übernahme des Standards zur Anforderung von Web-Push war ein möglicher Schritt. Die Spezifikationen mussten in dieser Richtung aktualisiert werden, um eine Verschlüsselung (RFC8291) zu verlangen und Autorisierungen mit VAPID (RFC8292) zu verarbeiten. Die Verwendung des Standards wird hoffentlich die Akzeptanz fördern, da die serverseitige Implementierung gleichzeitig für Webanwendungen verwendet werden kann.

Ende 2024 habe ich begonnen, Vollzeit an UnifiedPush zu arbeiten.

Durch die Zusammenarbeit mit COVESA konnte ich auch Sunup, einen Distributor, der Mozillas Push-Server „autopush” nutzt, hinzufügen und ein selbst hostbares Backend für autopush hinzufügen. Diese Funktion wird derzeit integriert.

NLnet bot mir die Möglichkeit, viele noch ausstehende Dinge zu verbessern, eine Migrationsfunktion zum Protokoll hinzuzufügen, mit der man einen Fallback-Dienst erhalten kann, wenn der selbst gehostete Server ausfällt, die eigentlichen Web-Push-Spezifikationen auf Mastodon zu implementieren und Web-Push/UnifiedPush zu einigen Anwendungen hinzuzufügen. Dazu gehören Fennec/IronFox, Forks von Firefox, sodass wir nun Push-Benachrichtigungen mit Webanwendungen erhalten können. Dazu gehören auch SimpleX (wird integriert), Nextcloud (wird integriert), DeltaChat (TODO) und flatline (TODO), eine selbst gehostete Version des Signal-Servers, die hoffentlich in die Signal-Server integriert wird.

Die Idee dahinter ist, den Netzwerkeffekt zu verstärken: Je mehr Anwendungen UnifiedPush unterstützen, desto relevanter wird UnifiedPush für die Nutzer und desto mehr Nutzer werden UnifiedPush verwenden. Wenn die Zahl der UnifiedPush-Nutzer steigt, werden die Entwickler von Anwendungen dazu veranlasst, das Protokoll zu unterstützen. Letztendlich können wir unser Telefon mit dem gewünschten Push-Dienst verwenden, um auch ohne die Play Services die erwartete Benutzererfahrung zu erhalten.

Rückblick

Es war Zufall, dass ich UnifiedPush gestartet habe, und das Projekt hätte ohne andere Projekte wie F-Droid, gotify, matrix, Fluffychat oder Fedilab und viele andere sowie ohne die Hilfe vieler Menschen niemals existiert.

Ich denke, das zeigt, wie vorteilhaft das FOSS-Ökosystem für alle sein kann. Ich entwickle Sunup, trage aber oft zu ntfy bei. Die Projekte könnten als „konkurrierend” angesehen werden, sind es aber nicht: Die Anwendungen erfüllen unterschiedliche Bedürfnisse. Wir haben nichts zu gewinnen oder zu verlieren, wenn ein Nutzer die eine App der anderen vorzieht. Aber wir alle gewinnen, wenn ein Nutzer sich für eine der beiden entscheidet, egal welche, da dies den Netzwerkeffekt verstärkt.

Wenn UnifiedPush vor fünf Jahren nicht gestartet worden wäre, hätte sicherlich seitdem ein ähnliches Projekt begonnen. Dies war etwas, worauf die mobile FOSS-Community gewartet hatte, und es gab bereits einige Forschungsarbeiten zu diesem Thema.

Mir war nicht bewusst, wie viele Dinge mit Push-Benachrichtigungen verbunden sind. Es ist verständlich, dass eine einzige Instanz, die eine so wichtige Funktion bereitstellt, damit unglaubliche Macht erhält. Dies ist besorgniserregend, wenn ihre Lösung nicht den Prinzipien der geringsten Privilegien folgt, mit Systemrechten ausgestattet ist, Zugriff auf das gesamte System hat und „Funktionen” bietet, die wir nicht wollen, wie Werbung und Telemetrie.

Ich verstehe jetzt, warum Push-Server ein Instrument zur Massenüberwachung sein können und warum eine offene Lösung für die Widerstandsfähigkeit wichtig ist. Einige Netzwerke existieren außerhalb des Internets, einige Regionen der Welt leiden unter Dienstsperren, einige Nutzer können von diesen Diensten ausgeschlossen werden. Wenn ein Dienst von einer einzigen Instanz kontrolliert wird, kann man nichts tun, wenn diese Ihr Gerät für zu alt hält, um es zu unterstützen. Eine offene Alternative anzubieten, ist eine Antwort auf all diese Probleme.

Die Idee ist nicht, alle zu einer offenen Lösung zu bewegen, sondern ihnen die Freiheit dazu zu geben. Die Unterstützung dieser Alternativen verringert auch das Risiko des Machtmissbrauchs durch Google. Wenn Sie eine Anwendung entwickeln, fragen Sie sich, wie schnell Sie sich von einer Sperrung durch Google erholen könnten.

Es ist unglaublich, Vollzeit an UnifiedPush zu arbeiten. Ich bin sehr froh, dass es eine Stiftung wie NLnet gibt. Ich hoffe, dass meine Arbeit für das Projekt und für die meisten Nutzer von Nutzen ist. Als alles begann, hätte ich mir nicht im Traum vorstellen können, dass ich daran arbeiten würde. Ich wollte einfach nur meine Matrix- und Mastodon-Benachrichtigungen ohne die Play Services.

Ich würde gerne weiterhin täglich an UnifiedPush arbeiten, und es gibt wahrscheinlich noch jede Menge zu tun, insbesondere für Linux-Geräte, und viele Apps, auf die die Funktion portiert werden könnte. Aber die Mittel von NLnet sind nicht unbegrenzt, unsere Hauptziele sind erreicht – Verbesserung des Protokolls, Verbesserung des bestehenden Codes und der Dokumentation, Stärkung des Netzwerkeffekts auf Android – und ich möchte nicht den potenziellen Platz eines anderen Projekts einnehmen.

Unter anderem müssen wir noch die Bibliotheken für UnifiedPush unter Linux verbessern, und es wäre toll, eine Benutzeroberfläche für KUnifiedPush zu haben, um es auf Flatpak zu veröffentlichen. Es gibt einige wichtige Anwendungen, wie z. B. den Mozilla-Synchronisierungsdienst, die eine Zulassungsliste autorisierter Push-Server verwenden, was den Zweck des Selbsthostings zunichte macht: Es wäre toll, einen besseren Anti-SSRF-Mechanismus zu implementieren. Wir werden diese und andere Blöcke wahrscheinlich gemeinsam erstellen müssen. Wenn Sie einen Beitrag leisten möchten, zögern Sie nicht, uns eine PM auf Mastodon zu senden oder dem UnifiedPush Matrix-Raum beizutreten.

UnifiedPush in 5 Jahren

Das Beste, was UnifiedPush auf Android in 5 Jahren passieren könnte, wäre, dass es nicht mehr existiert.

Wenn Android uns eine System-API zur Verfügung stellen würde, mit der der Benutzer seinen Push-Dienst selbst definieren kann, würden wir UnifiedPush nicht mehr benötigen. Passkeys (API zum Anmelden ohne Passwörter) wurden früher nur von den Play Services bereitgestellt. Heute ist Android, wahrscheinlich um die Akzeptanz zu erhöhen, zu einer System-API (Credential Provider) migriert, damit jeder Passwort-Manager den Dienst anbieten kann. Mit einer Push-Dienst-API wäre UnifiedPush gewissermaßen in das Betriebssystem integriert worden. Die Anwendungen würden wie wir Push-Endpunkte erhalten und sie würden Web-Push-Anfragen gemäß den Standards senden, wie es Webanwendungen tun, wie es UnifiedPush tut. Die Migration von UnifiedPush wäre minimal.

Wenn es uns gelingt, eine solche Push-Service-API zu realisieren, können wir davon ausgehen, dass viel mehr Apps diese Funktion unterstützen werden. Und wir werden endlich die Dienste auswählen können, denen wir vertrauen möchten.

Hoffentlich kann die Arbeit an UnifiedPush in diese Richtung vorantreiben, indem sie die Nachfrage steigert und den Bedarf hervorhebt.

Unter Linux hängt die Akzeptanz meiner Meinung nach stark davon ab, wie sich das mobile Linux-Ökosystem entwickelt. Ich persönlich denke und hoffe, dass es in die richtige Richtung geht. Und ich denke, dass in dieser Hinsicht in fünf Jahren viel passieren kann.

Eine Übersetzung von s3nnet