Interview mit Tobias Fella zum Matrix-Client NeoChat
Dies ist die erste Folge einer lockeren Reihe von Interviews mit Linux- und Open Source-Entwicklern aus Deutschland und dem deutschsprachigen Raum. Heute erzählt Tobias Fella etwas über die Entwicklung des Matrix-Clients NeoChat.
LN: Carl Schwan und Du habt der Matrix-Community mit NeoChat einen neuen Client beschert, der ein konvergentes User-Interface aufweist und am Desktop wie unter Plasma Mobile eine gute Figur macht. Dabei habt Ihr das kaum mehr weiter entwickelte, in C++ und QtQuick Controls 2 realisierte Projekt Spectral geforked. Was waren Eure Beweggründe für einen neuen Client?
TF: Das hat hauptsächlich zwei Gründe: Wir arbeiten in KDE schon seit Längerem daran, unsere Kommunikation von IRC und Telegram wegzubringen, wobei ein eigener Client natürlich hilft, Leute zu Matrix hinzubewegen. Außerdem brauchen wir einen guten Matrix-Client für Plasma Mobile und da wir mit QtQuick und Kirigami eine gute Grundlage für konvergente Programme haben, hat sich das angeboten.
Und weil die wichtigen Teile von Qt und den KDE Frameworks auf vielen Plattformen funktionieren, gibt es damit auch noch einen neuen Matrix-Client für Windows, macOS und Android.
LN: Gerade ist mit Neochat 1.1.1 die dritte Version nach der stabilen 1.0 im Dezember erschienen. Ihr habt einige neue Funktionen implementiert, einige größere Brocken fehlen aber noch. Kannst du den Lesern etwas über eure Roadmap verraten?
TF: Der nächste größere Teil, den wir entwickeln, ist die Ende-zu-Ende Verschlüsselung, das wird einige Zeit brauchen. Danach kommen wahrscheinlich Sprach-/Videoanrufe, wobei da selbst die Matrixspezifikation und die meisten Matrix-Clients noch nicht sehr weit sind. Bei der Entwicklung von den Anrufen wollen wir mit den Entwicklern von Nheko (einem anderen Matrix-Client) zusammenarbeiten, da Nheko schon grundlegende Sprach- und Videoanrufe unterstützt und wir damit hoffentlich doppelte Arbeit bei neuen Features sparen können. Außerdem arbeiten wir natürlich immer an Verbesserungen im User Interface, an Bugfixes und Performanceverbesserungen. –
LN: Besonderes Augenmerk legen potenzielle Anwender auf Ende-zu-Ende-Verschlüsselung. Viele wollen NeoChat erst einsetzen, wenn E2EE umgesetzt ist. Viele Clients, die sich E2EE als Entwicklungsziel auf die Fahnen geschrieben hatten, existieren nicht mehr. Kannst Du etwas zu den Problemen der Implementierung sagen? Könnt ihr euch bei Element (ehemals Riot) diesbezüglich etwas abschauen?
TF: Das Problem bei der Implementierung von E2EE ist, dass es viel Arbeit ist: die grundlegenden kryptografischen Funktionen müssen implementiert werden, dann die Infrastruktur zur Schlüsselverwaltung. Das ganze muss dann so in den Client eingebunden werden, dass das Interface auf die entschlüsselten Events zugreifen kann, als wären es normale Events. Dann kommen noch andere Sachen dazu: Verifizierung von anderen Geräten und Benutzern, sicheres Speichern von den verschiedenen Schlüsseln und so weiter.
Und weil das ganze sicherheitskritisch ist, muss es natürlich gut getestet werden. Selbst wenn die Implementierung richtig ist, können einige Dinge schiefgehen, die dem Benutzer dann gut mitgeteilt werden müssen. Bei Element kann man sich dabei ein paar Sachen abschauen.
Die meisten kryptografischen Funktionen, die gebraucht werden, sind in einer Bibliothek implementiert, die von den meisten Matrix-Clients verwendet wird. Danach wird es etwas schwieriger, weil Element nicht in C++ programmiert ist und intern anders strukturiert ist als NeoChat und die Bibliothek libQuotient, wodurch man nicht alles direkt übernehmen kann. Im User Interface kann man sich dann wieder anschauen, wie andere Clients mit den Details der Verschlüsselung umgehen und sich davon inspirieren lassen.
Tobias, vielen Dank, dass Du Dir Zeit zur Beantwortung der Fragen genommen hast.
Schreibe einen Kommentar