Das Voptop „rolling release“ das ich im letzten Blogbeitrag bereits angekündigt habe, läuft fröhlich vor sich hin. Bisher habe ich bereits ca. 5 kleine Releases in den „snapcraft store“ vorgenommen. Im Wesentlichen waren es bisher Fehlerkorrekturen, jetzt laufen die ersten größeren Releases ein. Aktuell überarbeite ich insbesondere das UI und modernisiere es. Dabei versuche ich auch die „Usability“ zu verbessern und auf Richtung Gruppen-Chat, Gruppen-Videokonferenzen, Screensharing um zu bauen, hin zu einem Kollaborationstool. Ich denke, dass man Voptop damit auch auf lange Sicht in etwas Vermarktbares verwandeln kann und quasi einen Konkurrenten zu „MS- Teams“, „Slack“ oder „Zoome“ aufbauen kann.

Alt vs. Neu

Alt vs. Neu

Zunächst einmal frohes neues Jahr! Möge 2023 besser werden als 2022, es gibt viel Luft nach oben!

Zwischen den Jahren bin ich dann tatsächlich dazu gekommen die neue Beta 1.5.0 fertig zu machen. Im Grunde bestand das „fertig machen“ daraus, IPv6 zu finalisieren und alle noch offenen Punkte in die Version 1.5.1 zu verschieben.
Da einige umfassende Erweiterungen und Änderungen anstehen habe ich mich entschlossen die 1.5 quasi als „roling release“ zu betrachten. Dabei wird primär das snappy Installationspaket berücksichtigt und alle andere werden nur ausgeliefert, wenn die Abwärtskompatibilität bricht. Die Version 1.5.0 steht aber wie immer für alle Plattformen bereit untet https://www.voptop.com und natürlich im Snapcraft store https://snapcraft.io/voptop.

Es ist noch kein Jahr her, seit dem letzten Release. Gute drei Monate hätte ich noch, aber die neue Beta Version 1.5.0 von Voptop ist auch noch nicht fertig. Ich habe mich entschieden die neue Beta Version 1.5.0 in „Häppchen“ zu veröffentlichen, damit sie nicht so lange bei mir alleine „reift“. In den nächsten Tagen kommt also Voptop mit IPv6 und einer ganzen Reihe Crash Fixes. Irgendwann im neuen Jahr dann das überarbeitete UI.
Mit der Überarbeitung des UI möchte ich Voptop auch ein wenig neue ausrichten, ich möchte es mehr in richtig „Collaboration - Tool“ entwickeln. Das bedeute das Gruppen-Chats und Gruppenkommunikation im allgemeinen in den Fokus kommen werden, alles natürlich weiterhin unter den Gesichtspunkten des Themas Sicherheit und auch Anonymitätswahrung.

Fast ein Jahr hat es jetzt gedauert bis ich mit der im letzten März angekündigten neuen Voptop Beta fertig geworden bin. Dieses Update ist so ziemlich das umfangreichste, dass Voptop in seiner langen Betaphase je bekommen hat. Dabei bricht es auch die Kompatibilität zu den Vorgänger Versionen. Voptop ist in dieser Version in aller erster Linie schlanker geworden, die libxml2¹ ist entfernt wurden, damit ist auch der Ressourcen verbrauch ein gutes Stück gesunken.
Im Weiteren habe ich diesen großen Versionssprung genutzt und bei der Gelegenheit die Architektur von Voptop ein wenig aufgeräumt und ein paar Architektursünden behoben. Einen nennenswerten Stabilitätsgewinn kann man dem neuen Versionssprung auch beimessen.
Zugegeben, für so viel und so lange Arbeit, ist für den Nutzer auf den ersten Blick nicht viel „rumgekommen“, aber um so mehr für die Portierbarkeit (z.B. auf Android & iOS) und Zukunftssicherheit von Voptop.
Wie immer ist die neue Version auf https://www.voptop.com zu finden und außerdem im Snapcraft² store als „snappy“³.

Eine kleine Auflistung aus meinem Ticketsystem was so alles in Voptop 1.4.0 eingeflossen ist. Wenn ich das gerade so rekapituliere doch mehr als gedacht.

0000033: [General] Remove libxml2 (Robert Stiehler)
0000071: [General] Refactore client to client interface (Robert Stiehler)
0000070: [General] No notification if status of any contact changes (Robert Stiehler)
0000051: [General] Refactoring of Audio and Video processing (Robert Stiehler)
0000052: [General] Voptop crashes/freeze on muting while video playback (Robert Stiehler)
0000050: [General] Very poor audio quality (Robert Stiehler)
0000054: [General] Fix receive and send package "throw away" in Video chat/Screen sharing (Robert Stiehler)
0000069: [General] Deadlock when closing screen sharing session (Robert Stiehler)
0000066: [General] All thrown exceptions should be on stack (Robert Stiehler)
0000065: [General] CAudioLevelMeter_widget::redrawTimerExpired() called endless often (Robert Stiehler)
0000064: [General] Refactoring by clang analyzer (Robert Stiehler)

Ausblick

Es gilt, was immer gilt; nach dem Release ist vor dem Release. Ich bin noch lange nicht am Ziel, es wird weitergehen. Was die Zukunftssicherheit von Voptop betrifft, gibt es noch ein extrem wichtiges Thema zu vervollständigen, und das ist die IPv6 Unterstützung. Außerdem möchte ich das UI von Voptop grundlegend überarbeiten. Dafür werde ich mir auf jeden Fall viel Zeit nehmen. Der nächste Version-Sprung wird also wieder ein „Minor“-Release, aber hoffentlich nicht wieder so furchtbar lange auf sich warten lassen (Zu meiner Verteidigung, ich habe nebenbei ein Haus ausgebaut :-P, dazu vielleicht bei Gelegenheit an anderer Stelle mehr).


1) http://www.xmlsoft.org/
2) https://snapcraft.io/
3) https://snapcraft.io/voptop

Es ist wieder so weit, Voptop hat einen Stand erreicht, der ein neues Beta Release rechtfertigt. Die Beta 1.3.1 hat sich dieses Mal nicht nur der Stabilität gewidmet, sondern ein neues Feature mit gebracht. Voptop kann jetzt aus und eingehende Audiosignale analysieren und entsprechend die Lautstärke regulieren, um Rückkopplungen zu vermeiden. Außerdem wurden eine ganze Reihe von Bugs behoben und die allgemeine Stabilität immens verbessert. Lausig ist leider noch immer die Video/Audio Qualität im Allgemeinen, die steht mit unter ganz groß für das nächste Beta Release auf der Fahne.

Die nächste Beta Version wird ein großer Schritt werden. Ein mir sehr wichtiges Thema bei Voptop ist das reduzieren von Abhängigkeiten zu Bibliotheken. Derzeit verwendet Voptop die libxml2¹ für die Xml - Schnittstelle zur Inneren-Peer-to-Peer Schicht². Der Plan ist es nicht nur die libxml2 aus Voptop zu entfernen, sondern dabei auch gleich die Schnittstelle zwischen Äußeren-Peer-to-Peer³ Netzwerk zu Inneren-Peer-to-Peer² Netzwerk zu überarbeiten. In dieser Konsequenz wird Voptop die Abwärtskompatibilität verlieren. Das bedeutet, ein alter Client wird sich nicht mehr am zukünftigen Voptop-Netzwerk anmelden können und muss aktualisiert werden. Entsprechend wird das nächste Release 1.4.0 werden, aus Betasicht also ein „Minor“⁴ Release.

1) libxml2

2 & 3) Hybrides Peer - to - Peer

4) Versionierung

Seit Kurzem arbeite ich an einer Signalanalyse für Voptop. Analysiert werden soll das Audiosignal. Das erste Ziel ist es zu erkennen, ob man gerade selbst spricht, um in dieser Konsequenz dann die eigenen Lautsprecher runter zu regeln. Umgedreht soll das eigene Mikrofon runter geregelt werden, wenn man gerade Ton/Sprache übertragen bekommt. Es wird also die Amplitude berechnet.

Das Ganze hat den Sinn, Feedbackschleifen zu vermeiden. Zu diesem Zweck hab ich das Ganze jetzt zunächst visualisiert. Im nächsten Schritt versuch ich jetzt vernünftige Schwellenwerte zu definieren, bei denen ich dann die Tonwiedergabe bzw. Aufnahme jeweils runter drehe.

Wenn das funktioniert, versuch ich mich auch noch an einer Spektrumanalyse. In der Summe will ich vor allem die Audioqualität von Voptop massiv verbessern.

Für die Snappy User steht das ganze auch schon im Snapcraft Store unter „latest/edge“ zur Verfügung.

Als ich angefangen habe zu studieren, kam irgendwann um das Jahr 2005 das Thema „peer to peer“ Streaming an vielen Ecken des Internets auf. Das war der Zeitraum, in dem man versuchte „peer to peer“ Techniken aus der „Schmuddelecke“ des illegalen Filesharing heraus zu holen, mit der man damals (und auch noch Heute) das Thema „peer to peer“ im medialen Mainstream im Wesentlichen assoziierte. Natürlich war „peer to peer“ damals wie Heute eine völlig neutrale Technik und war nie „schmuddelig“, Film und Musikindustrie haben es im Kampf gegeben illegales Filesharing lediglich so gelabelt. In dieser Zeit kam damals der Streaming-Dienst Joost¹ auf, der sich das Ziel setzte, die klassische TV-Übertragung via Satellit und Kabel durch Streaming abzulösen. Dabei wollte man nicht mittels eigener Serverinfrastruktur streamen, sondern über „peer to peer“. Also die Last auf möglichst viele Schultern verteilen und jedem der einen Stream ansieht dazu einbinden selbigen auch wieder an möglichst viele andere weiter zu leiten. Joost bekam damals in der Fachpresse viel Aufmerksamkeit und hat auch einen viel versprechenden Start hingelegt. Immerhin sollen damals über eine Million freiwillige Betatester mitgewirkt haben (einer davon war ich). Joost kam dann aber nicht weit, es ging „sang und klanglos“ unter.
Die Idee und Technologie waren aber super, so zumindest nach wie vor meine Meinung. Durchgesetzt hat sich am Ende aber eine andere Form des Streaming. Im Grunde die nicht lineare, die um Livestreaming ergänzt wird. Das ist im Wesentlichen, was wir vom Platzhirsch Youtube kennen. Videos die man zu jederzeit abrufen kann und Livestreams die nach dem Stream selbst auch wieder zu Videos werden, die man jederzeit abrufen kann. Joost hatte seinen Schwerpunkt auf das lineare Fernsehen, das ist gescheitert.
Jetzt sind wir ca. 10 Jahre weiter und es haben sich neue Technologien aufgetan, Blockchains zum Beispiel. Blockchains sind im Grunde kryptografisch manipulationssichere Datenverkettungen. Und verketten kann man daran praktisch alles. Hier entsteht eine interessante Kombinations Möglichkeit, aus „peer to peer“ und blockchain. Man nehme eine Blockchain als Index für Videos und ein „peer to peer“ Netzwerk, um selbige zu verteilen. Schwups hat man ein zensursicheres dezentrales Videoportal. Schlau Leute und gute Entwickler hatten diese Idee und haben sie auch schon umgesetzt. Die Umsetzung trägt den Namen lbry², sie stellt zum einen eine Website da, mit der man Videos abrufen kann, wie man es von Youtube und Co. gewohnt ist, zum anderen einen Desktop Client, mit dem man richtig am Netzwerk teilnimmt, also auch selber Video weiterverbreitet. Die Website ist dabei auch nur ein Client. Ferner ist das ganze open source, das heißt, jeder kann einen eigenen Client programmieren und veröffentlichen.
Ich könnte mir vorstellen, dass sich das durchsetzt. Derzeit wird lbry zwar überwiegend von der Kryptowährungsszene und den Verschwörungstheoretikern dieser Welt genutzt, die von der unzenzierbarkeit angelockt werden. Aber, da über die Blockchain auch eine Kryptowährung entsteht, die zur Monetarisierung von Videos beiträgt sowie Videos kommerziell vertrieben werden können, kann ich mir vorstellen das absehbar viele „Content Creator“ ihren Weg auf die Plattform finden. Auf jeden Fall ein spanendes Projekt und ich habe mich entschieden, alles was ich insbesondere mit Voptop an Videos mache dahin umzuziehen.

1) Joost
2) Lbry

Es war mal wieder soweit, es wurde ein Voptop Release fertig. Mit diesem Release ist Voptop endlich unabhängig von libnice¹ und ich verabschiede mich damit vom ICE² Protokoll.
Der Verbindungsaufbau mit ICE hat einfach viel zu lange gedauert und sehr zuverlässig war das auch nicht. Außerdem war es am Ende doch immer so, dass es nie ohne TURN³ Server ging. Also habe ich mich entschiedenen ein Voptop eigenes Relay bzw. Gateway zu schreiben, für den Fall das keine direkte Kommunikation zwischen einzelnen Voptop peers zustande kommen kann oder wegen Inkompatibilitäten zwischen IPv4 <-> IPv6 und Ähnlichem.
Das war alles andere als einfach, ist jetzt aber fertig und bisher scheinbar sehr stabil. Der Verbindungsaufbau mittels meines Gateways ist mehr als zehnmal so schnell, wie es mit libnice in Kombination mit einem TURN-Server war.
Außerdem hab ich eine Reihe von Bugs behoben, von nicht korrekter Initialisierung der Audioaufzeichnung für Videochats bis hin zum fixen der Webcam Auswahl für Videochats.
Ferner kann man mittlerweile Voptop nicht nur auf der Voptop Webseite runterladen, sondern auch im Snapcraft Store.
Von Flatpak zur Erstellung eines Installationspaketes hab ich mittlerweile wieder abstand genommen. Das Argument für Flatpak, nämlich das es vollständig Open Source ist, ist leider auch sein stärkstes Gegenargument. Man hat zwar mit Flathub⁴ einen zentrale Paketquelle, diese wird aber durch Github⁵ gespeist (es gibt also keine eigene vernünftige Infrastruktur). Um es kurz zu machen; auf Github habe ich keinen Bock, ich will da keinen Account für Voptop haben und außerhalb einer allgemein bekannten und zugänglichen Paketquelle macht das keinen großen Sinn.

1) libnice
2) ICE
3) Turn
4) Flathub
5) Github

Es ist bald mal wieder soweit, absehbar werde ich eine neue Version von Voptop¹ freigeben. Womit ich mich wieder meinem alten „Voptop Release - Management“² Problem annähere. Bis jetzt bin ich noch immer nicht so richtig dazu bekommen, mir mittels Jenkins einen Build Server aufzusetzen, das hole ich jetzt nach. In dem Zuge werde ich jetzt erstmals zusätzlich zu „deb“³ Paketen auch „Snappy“⁴ Pakete anbieten. Snappy ist ein Paket Format von Canoncial⁵ (dem Unternehmen hinter Ubuntu⁶ Linux).
Für das Erste werde ich mich auf das automatisierte bauen von Snappy Paketen konzentrieren, denn ich bin mir nicht sicher, ob ich mit Voptop noch langfristig die Paketierung mit deb weiter unterstützen will (der Aufwand ist einfach zu hoch, man paketiert ab Ende für x Distributionen und deren Versionen).
Snappy bringt eine Vielzahl von Vorteilen gegenüber deb. Der wichtigste Vorteil ist für mich, dass ich mit einem einzigen Installationspaket sehr viele Linux Distributionen auf einmal unterstütze⁷. Auch sehr wichtig für mich ist, dass ich mit Snappy einen zusätzlichen „Vertriebskanal“ für Voptop bekomme (der ist aber auch einer der Kritikpunkte von Snappy, dazu später mehr), den Snappy App-Store.

Das Paketieren mit Snappy ist auf den ersten Blick sehr einfach. Man schreibt eine Konfigurationsdatei (im yaml⁸ Format). In dieser Konfigurationsdatei gibt man einige Metadaten an (Name, Beschreibung etc.), wo der Quellcode zu finden ist (im Dateisystem, in einem Source-Repository oder Ähnlichem) und gibt ein sogenanntes „build plugin“ an (make, cmake, qmake etc.). Im Weiteren spezifiziert man die Abhängigkeiten, die benötigt werden, um das Projekt zu bauen (im Grunde die deb - dev Pakete der verwendeten Bibliotheken) und die Pakete, die benötigt werden, um die Anwendung laufen zu lassen.
Außerdem bestimmt man eine Art Laufzeitumgebung, core18 oder core20 zum Beispiel. Da das Ganze von Canoncial kommt, basiert die Laufzeitumgebung natürlich auf Ubuntu (jeweils die LTS Versionen, wie man schon am Namen core18 und core20 sieht). Im Wesentlichen wird am Ende mit Snappy eine Ubuntu Distribution um die eigentliche Anwendung herum aufgebaut, die aber nur die Abhängigkeiten besitzt, welche die mit Snappy paketierte Anwendung zur Laufzeit braucht (was die Pakete im Vergleich zu „nativ“ paketierten Anwendungen immer noch extrem „voluminös“ macht).

Einer der am häufigsten kritisierten Eigenschaften von Snappy ist, dass man die Paketquelle nicht frei wählen kann. Canoncial betreibt die einzige Paketquelle, alternative App-Stores kann man nicht verwenden (zumindest ist das bisher so). Für mich ist das zumindest für das erste kein Problem, ob ich das jedoch dauerhaft will weiß ich noch nicht. Auf jeden Fall gibt es aber Alternativen, am interessantesten scheint mir dabei Flatpak⁹ zu sein (damit habe ich mich aber noch nicht tief greifend genug befasst). Flatpak hat wohl derzeit einer der größten User und Entwicklungs Basen, absehbar werde ich mich also auch damit befassen.

1) Voptop
2) Voptop Release - Management
3) deb
4) Snappy
5) Canoncial
6) Ubuntu
7) Unterstützte Distributionen
8) YAML
9) Flatpak