Alle vorhandenen Boten haben ihre Vor- und Nachteile, aber jeder von ihnen zieht die Decke aufgrund der Inkompatibilität mit anderen auf die Seite - und die Benutzer leiden darunter.
XMPP könnte ein einziger Standard werden, aber es erschien im Gegensatz zu E-Mail relativ spät und konnte nicht genügend Publikum gewinnen, so dass Unternehmen es nicht bereits ablehnen konnten. Schließlich wurde ihnen schnell klar, dass es nicht viel zu verdienen gibt, ohne das Publikum in ihrem eigenen Ökosystem zu halten. Außerdem musste XMPP aufgrund der Fülle an Erweiterungen, von denen viele trotz ihrer Bedeutung im experimentellen Status blieben und einige sich vollständig duplizierten, genügend Mängel aufweisen.
Nachdem wir in der „neuen wunderbaren Welt“ von einem Dutzend Instant Messenger im Smartphone gelebt haben und alle Mängel dieses Zustands gespürt haben, sind wir endlich bereit für etwas Neues.
Und ja, wir brauchen einen neuen Standard!
Ein ausgezeichneter Future Messenger erfüllt die folgenden Anforderungen: Gewährleistung von Zuverlässigkeit, Sicherheit durch offene Entwicklung und Dezentralisierung, Portabilität (plattformübergreifend), Multiprotokoll (Fähigkeit zur Verbindung mit anderen Kommunikationsnetzwerken) und Benutzerfreundlichkeit.
Warum ist alles so schlecht?
Aber lassen Sie uns zunächst herausfinden, warum nicht jeder zu einem bereits beliebten == zentralisierten Messenger wechselt, ob es sich um eine bedingte WhatsApp oder beispielsweise ein Telegramm handelt, das in Russland ein beachtliches Publikum hat.
Durch das zentralisierte Bauen können die Eigentümer natürlich mehr Geld verdienen und damit nicht nur für die Entwicklung bezahlen, sondern auch viel Geld in Werbung und sogar in die Verherrlichung praktisch fehlender Funktionen wie beispielsweise der Service-Sicherheit investieren. Gleichzeitig kann der Eigentümer jedoch plötzlich entscheiden, den Dienst zu schließen, den Traktor, um das Kabel aus dem Rechenzentrum zu entfernen, oder nur ein Messenger kann im Gebiet eines bestimmten Landes verboten werden. Vielleicht nicht unbedingt aus politischen Gründen und auf Wunsch von Inhabern von bedingten Urheberrechten kann es viele Gründe geben. Es ist gut, wenn Telegram trotz der unbedeutenden Größe des Marktes in Russland weiterhin mit unterschiedlichem Erfolg arbeitet. Dies liegt jedoch an den persönlichen Konten des Eigentümers. Wenn Facebook dieselbe WhatsApp blockiert, ist es unwahrscheinlich, dass Facebook viel investiert, um die Sperren zu umgehen.
Es ist schwierig, sofort für alle zentralisierten Boten zu sprechen, die unter einem Kamm sammeln. Es gibt ein absolutes Übel mit einem proprietären Client, Server und Protokoll, die sogar nur auf einigen der beliebtesten Plattformen funktionieren und keine Verschlüsselung haben. Es gibt auch relative Güte, zum Beispiel den Signal Messenger, der vollständig geöffnet ist, aber die Server unterstützen keinen Verbundmodus, weshalb jeder vom zentralen Server mit allen daraus resultierenden Konsequenzen abhängig ist. Hier sollte die Klassifizierung nach einem anderen Prinzip erfolgen, dies geht jedoch über den Rahmen dieses Artikels hinaus.
Warum nicht zu etwas Bundesartigem wechseln? Zum Beispiel die gleiche Matrix. Ich werde nicht über HTTP Long Polling, schlechte Server-Ausfallsicherheit und die explizite Geekiness der Client-Oberfläche sprechen - all dies sind lösbare Aufgaben, wenn auch nicht trivial (auf globaler Ebene ändert dies nichts). Ich finde es gut, dass die Entwickler die Erfahrungen mit XMPP berücksichtigt und gemeinsame Spezifikationen anstelle einer Reihe unabhängiger XEPs entwickelt haben, aber dies ist nur einer der Nachteile von XMPP. Ein weiteres Problem ist das klassische Gerät des Bundesnetzwerks, bei dem wir gezwungen sind, einen Server auszuwählen und seinem Besitzer zu vertrauen, dass er sicherstellt, dass der Server funktioniert und ihn nicht schließt. Und im Falle eines weiteren Ausfalls des Rechenzentrums sind wir von der Welt abgeschnitten und können nicht mit dem vorherigen Konto auf einem anderen Server kommunizieren. Selbst wenn Sie ein neues Konto erstellen und die Liste Ihrer Kontakte vom alten Server auf dieses Konto übertragen, müssen Sie bei der Kommunikation erneut bestätigen, dass Sie es wirklich sind und nicht jemand, der Sie vorstellt.
In diesem Fall den Server vielleicht komplett verlassen? Es gibt eine Reihe von Instant Messenger, die auf serverloser Technologie basieren. Ein Sonderfall ist hier das in engen Kreisen beliebte Firechat, das ein Mesh-Netzwerk aus WLAN- und Bluetooth-Geräten verwendet, um mit Benutzern zu kommunizieren. Dieser Messenger funktioniert wirklich gut, wenn sich alle Benutzer beispielsweise auf den Bereich konzentrieren. Dies ist jedoch eine ziemlich spezifische Situation, und selbst wenn wir uns eine Situation vorstellen, in der jeder Bewohner des Planeten eine Anwendung installiert, entstehen viele andere Probleme, angefangen von Netznetzbrüchen durch geografische Zeichen und der Geschwindigkeit des Nachrichtenaustauschs mit entfernten Benutzern bis hin zur Menge der auf Geräten gespeicherten Daten. Aber wahrscheinlich ist dieser Bote aus der Gesamtmasse ausgeschieden und in unserem Vergleich überflüssig. Es ist eher experimentell als benutzerzentriert.
Es gibt auch Projekte wie Tox, die versuchen, einen P2P-Messenger zu implementieren. Mit diesem Ansatz können Sie sich keine Sorgen um die Sicherheit des Servers machen, und es ist fast unmöglich, einen solchen Messenger zu blockieren. Tox hat viele Probleme, aber dies ist ein sehr interessantes Projekt, das eine eigene Nische hat. Es macht keinen Sinn, die spezifischen Nachteile von Tox aufzulisten, da sich das Projekt weiterentwickelt und trotz der Tatsache, dass p2p-Dienste viel schwieriger zu entwickeln sind, wenn Sie eine solche Aufgabe festlegen, können Sie verschiedene interessante Architekturen für den Aufbau eines solchen Netzwerks entwickeln: mit eigenen Vor- und Nachteilen, unterschiedlichen Anforderungen an die Breite des Internetkanals und Der Speicherplatz auf dem Gerät mit Superknoten, gleichzeitiger Anmeldung von verschiedenen Geräten und sogar Offline-Nachrichtenübermittlung. Häufig ist jedoch immer eine erhebliche Verkehrsredundanz im Vergleich zur Client-Server-Architektur und ein erhöhter Batterieverbrauch auf Mobilgeräten, da ständig eine große Anzahl von Verbindungen und verschiedene Berechnungen durchgeführt werden müssen.
Obwohl p2p eine interessante Technologie ist, wird es sich bei Bedarf als unwirksam herausstellen, Ihre Koordinaten an Retter zu senden, die sich irgendwo in einem Baum in der Taiga befinden, fast ohne Internetverbindung und mit 1% Batterieladung.
Wie kann ich das beheben?
Daher möchte ich eine hybride Client-Server-Architektur einführen, die das Beste aus den vorhandenen Ansätzen herausholt und deren Nachteile vermeidet.
Damit unser Messenger mit den minimal erforderlichen Ressourcen auf Mobilgeräten funktioniert, verwenden wir das Client-Server-Modell, bei dem das Maximum an Rechenvorgängen und verkehrsintensiven Ressourcen auf den Servern konzentriert ist und auf der Clientseite die Daten entschlüsselt und dem Benutzer angezeigt werden.
Adressierung
Jeder Benutzer erhält seine Adresse im Format E-Mail oder XMPP, dh Spitzname @ Domäne. Im Gegensatz zu den oben genannten Diensten spielt die Angabe einer Domäne in dieser Architektur jedoch nicht dieselbe wichtige Adressrolle.
Domains werden eher als Spitznamen-Registrare verwendet, um die Möglichkeit auszuschließen, dass alle vorhandenen Spitznamen absichtlich oder unbeabsichtigt belegt werden.
Domains kosten im Internet Geld, was eine Massenregistrierung nicht ausschließt, aber ihren Umfang erheblich einschränkt. Bei zentralisierten Diensten erfolgt der Zugriff häufig über eine Verbindung zu einem Mobiltelefon, was ebenfalls kein ausschließlicher Faktor ist, aber SIM-Karten werden auch nicht aus der Luft genommen! In diesem Zusammenhang frage ich mich übrigens, wie sie dies in https://toxme.io/ bekämpfen werden - einem Dienst für Tox, mit dem Sie lange Schlüssel mit einem kurzen Spitznamen verknüpfen können. Ich sehe keinen Grund, warum sie nicht mit Milliarden von Junk-Spitznamen gespammt werden können.
Darüber hinaus kann die Domäne für verschiedene Konten für Heim und Arbeit sinnvoll sein. Oder um ein internes Unternehmensnetzwerk zu organisieren.
Aus Sicht des Benutzers müssen Sie, um an jemanden schreiben zu können, dessen vollständigen Login oder öffentlichen Schlüssel kennen.
Wenn aus Sicht der Serversoftware ein Benutzer nach seinem Fingerabdruck gefragt wird, sucht der Server in seiner Tabelle nach dem damit verbundenen Login. Wenn er sofort nach dem Login gefragt wird, wird dieser Schritt übersprungen. Anschließend werden die Anmeldung und die Adresse des Servers vorgenommen, an den das Konto derzeit delegiert ist. Wenn keine solchen Einträge vorhanden sind, wird davon ausgegangen, dass das Konto, das im Login nach @ angegeben ist, für das Konto verantwortlich ist.
Benutzerprofil
Die Clientanwendung speichert ein Benutzerprofil, das Folgendes darstellt:
- Vollständige Benutzeranmeldung
- Liste der Sicherungsserver
- Öffentlicher und privater Benutzerschlüssel
- Profilinformationen wie Kontaktliste, Chat-Einstellungen und Benutzerprofil
Die öffentlichen Schlüssel jedes Benutzers werden auf jeden der Server im Verbundnetzwerk verteilt. Der Benutzer kann sich bei jedem der Server anmelden, da bei der Authentifizierung kein in der Serverdatenbank gespeicherter Kennwort-Hash verwendet wird, sondern der private Schlüssel eines Benutzers.
Das Autorisierungsverfahren ist wie folgt: Der Server sendet einen zufälligen Datensatz mit dem öffentlichen Schlüssel des Clients an den Client, der Client entschlüsselt mit seinem privaten Schlüssel und sendet einen Hash der entschlüsselten Daten an den Server. Wenn die Daten-Hashes übereinstimmen, autorisiert der Server den Benutzer. Wenn der Benutzer den Server, zu dem die Verbindung hergestellt wurde, zuletzt geändert hat, werden gleichzeitig alle Server des Verbundnetzwerks über den neuen Standort des Benutzers benachrichtigt.
Das Fehlen der Notwendigkeit, sich das Passwort zu merken (der Client ermöglicht es Ihnen jedoch, den privaten Schlüssel zu verschlüsseln), vereinfacht sowohl die Interaktion mit dem Messenger als auch das Risiko des Verlusts Ihrer Schlüssel. Um dies zu vermeiden, wird empfohlen, sie auf andere Benutzergeräte zu duplizieren. Nichts hindert das Chatten unter demselben Konto von mehreren Geräten gleichzeitig. Die einzige Einschränkung besteht darin, dass alle mit demselben Server verbunden sein müssen, da sonst die Architektur zu verwirrend wird. Das ist aber kaum ein großes Minus.
Add-On für Browser
Bei vielen Produkten ist die Schwachstelle eine Webanwendung. Und diese Lösung hat natürlich viele Nachteile. Ein solcher Chat wird nicht heruntergeladen, während Sie offline sind. Dann müssen Sie auf einen vollständigen Download warten, und die Adresse wird möglicherweise blockiert oder der Server stürzt ab. Adressen manuell sortieren - das möchte ich nicht besonders.
Es besteht weiterhin die Möglichkeit, dass ein Angreifer eine Webanwendung hackt und einen Code einbettet, der alle Ihre Daten zusammenführt - auch nachdem der andere Teil der Anwendung sie für Sie entschlüsselt hat und Sie nicht einmal davon wissen.
In diesem Zusammenhang schlage ich vor, die Webanwendung als solche aufzugeben und ein Add-On für den Browser zu installieren, in dem per Definition alle diese Mängel fehlen.
Darüber hinaus müssen die Eigentümer der Webclient-Konfigurationsserver den Eintragsschwellenwert für die Erstellung ihres Servers nicht senken. Jeder Haushalt hat einen eigenen Server!
Transporte
Wer braucht einen Boten, mit dem niemand kommunizieren kann? Es gibt interessante Projekte ungewöhnlicher Boten, aber das Problem des Mangels an Publikum lässt sie nicht zumindest ein wenig an Popularität gewinnen. Infolgedessen gewinnen Boten mit einem großen Publikum häufig noch mehr Publikum, und Instant Messenger mit einem kleinen Publikum verlieren es. Und meistens kann diese Situation nur erhebliche Investitionen in Werbung verändern.
Außerdem erfordert dieser Zustand die Installation eines anderen Messenger, wenn Sie dringend jemanden kontaktieren müssen, der sich nicht in einem anderen Netzwerk befindet.
Daher muss der Server den Betrieb von Transporten zu Netzwerken von Drittanbietern unterstützen.
Wenn der Benutzer die Daten angibt, die in anderen Instant Messenger mit seinen Konten verbunden werden sollen, sieht er Personen aus den Netzwerken, die er in seinen Kontakten verbunden hat.
Die Verbindung zu Netzwerken von Drittanbietern wird auf der Serverseite hergestellt, und im Client werden die Kontakte mit minimalen Unterschieden als die gewöhnlichsten angezeigt. Beispielsweise wird das Symbol des Netzwerks angezeigt, von dem aus der Benutzer stammt.
Als Nachteil wird es notwendig, dem Server seine Daten anzuvertrauen, um eine Verbindung zu Netzwerken von Drittanbietern herzustellen. Nicht jeder ist bereit, seine Berechtigung an einen Server eines Drittanbieters zu delegieren. Daher müssen Sie die Erstellung eigener Server in jeder Hinsicht fördern.
Kryptographie
Natürlich kann ein dezentrales Netzwerkgerät nicht auf die Verschlüsselung aller übertragenen Daten verzichten, da wir nicht sicher sein können, dass selbst auf dem uns anvertrauten Server keine Art Lesezeichen integriert ist, das alle Daten zusammenführt.
Zuvor wurde bereits darauf hingewiesen, dass das Schlüsselpaar des Benutzers für die Autorisierung verwendet wird. Alle an andere Benutzer gesendeten Nachrichten werden ebenfalls mit dem privaten Schlüssel des Absenders signiert und mit dem öffentlichen Schlüssel des Empfängers verschlüsselt.
Hier gibt es nichts Neues, es werden Standard-GPG-Verschlüsselungstools verwendet.
Das Problem der Verschlüsselung in Gruppen wurde noch nicht behoben, aber Sie können wahrscheinlich den in Signal verwendeten Mechanismus verwenden.
Was wurde bereits getan?
Im Moment haben wir mit Tornado bereits einen Server in Python erstellt, der die Grundfunktionen des Messenger implementiert. Es gibt eine leicht eingefrorene Webversion, die in einen Zusatz für den Browser konvertiert werden soll. Es gibt eine Bibliothek in Rust, auf deren Grundlage der Client mit einer QML-Schnittstelle arbeitet.
Die Verbindung zum Server erfolgt über WebSockets, bei dem die Daten standardmäßig in das Binärformat für die CBOR-Datendarstellung serialisiert werden. Beim Herstellen einer WebSockets-Verbindung kann jedoch ein anderes Format angefordert werden, z. B. protobuf.
Ich halte es auch für wichtig zu beachten, dass der Client eine Unterteilung in eine Liste von Chats verwendet, sortiert nach dem Datum der neuesten Nachrichten, die in modernen Instant Messenger weit verbreitet sind, und einen traditionellen Dienstplan mit Sortierung der Kontakte in Kategorien. Bei aktiver Nutzung des Messenger müssen Sie mit einer großen Anzahl von Chats interagieren, und es wird schwierig, sie in einer sich ständig ändernden Listenreihenfolge zu suchen. Im selben Telegramm wird das Problem des Fixierens ausgewählter Chats am Anfang der Liste teilweise gelöst, dies ist jedoch nur eine vorübergehende Lösung des Problems.
→ Hier sind die Repositories , die unsere Erkenntnisse enthalten