Erst einmal Danke für das Engagement.
Ich möchte allerdings ein paar Kritikpunkte nennen, die mir auffallen. Wenn ich das richtig verstanden habe, wurde letztlich nur ein Workaround für etwas, das (bezüglich dieses Usecases) „broken by design“ ist, entwickelt – das ursprüngliche Problem wird dabei allerdings nicht beseitigt, sondern eher verfestigt.
Denn es passiert ja bei der Umsetzung dieses Features Folgendes: Es gibt dann zwei verschiedene Funktionen innerhalb der App. Die eine Funktion ist die eigentliche Funktion, die es bisher ausschließlich innehat, nämlich die Kommunikation mit dem Threema-Server und der Austausch von Nachrichten. Dieser Austausch ist designmäßig nur mit einer einzigen Appinstanz pro ID möglich – das bleibt auch in Zukunft so. Was neu hinzukommt, ist die zweite Funktion, nämlich eine Serverfunktionalität (SaltyRTC), mit dem sich alle Clients (z.B. Webapp) syncen können. Das ist klassischerweise eine Kompositionsbeziehung, denn die App/Serverinstanz kann ("wie bisher") alleine verwendet werden, eine Clientinstanz (z.B. Webapp) ist ohne App, die als Server fungiert, nicht überlebensfähig. Und das heißt: Threema bleibt weiterhin (und dann wohl für immer) ausschließlich geeignet für single-device, es gibt keinen echten Multi-Device-Support, sondern nur pseudo-"Multi"-Device-Support. [An dieser Stelle noch eine Nachfrage: Beim Senden von Nachrichten muss dann ja letztlich via RTC an den Server(=App) geschickt werden und von dort an den Threema-Server – das erzeugt doch dreifachen Traffic (2x up, 1x down)? Ich schicks erst "an mich selbst" und dann "raus" an Threema für den Empfänger.]
Denn ohne dieses Single-Device, das permanent online sein muss, funktioniert nicht. Und das ist eigentlich ein elementares Kriterium. Ich will unabhängig vom Handy (denn das ist 98% offline) am PC schreiben können (und auch vice versa, denn wenn das Handy online ist, ist zu 99,999% der PC offline). Bei Signal funktioniert das zum Beispiel, dort werden Websockets benutzt. Sollte ich etwas an der Funktionsweise missverstanden haben, wäre es nett, wenn die Stelle meiner fehlerhaften Interpretation aufgezeigt würde, aber ich denke schon, dass ich das nach Durchsicht von Thesis und Code richtig verstanden habe.
Und nach der Generalkritik bringe ich einen Lösungsvorschlag, das Posting soll ja auch konstruktiv sein. Ohne näher drin zu sein, könnte ich mir einen Multi-Device-Support wie folgt feststellen:
- Gleichberechtigte Endgeräte, initial – selbstverständlich offline – synchronisiert per Backup-Funktion (Import private key)
- Serverseitig wird statt einer einzelnen Verbindung pro ID, eine Liste von Verbindungen pro ID verwaltet
- Clientseitig kann eine Policy festgelegt werden – Server schickt an den/die Geräte, die den Einstellungen folgend bedient werden müssen (z.B. einige Vorschläge – 0: Nachrichten immer an beide Geräte schicken (puffern bis von allen abgerufen, ggf. mit Timeout (z.B. länger als 3 Tage wird es nicht aufm Server gepuffert, wenn mit mind. 1 Gerät schon abgerufen)), 1: An Gerät schicken, das sich zuletzt gemeldet hat (bei Start der Verbindungsaufbau bzw. App-Öffnung Syn/ack mit dem Server), 2: Prioritätsliste der Geräte; usw. da gäbe es einige Möglichkeiten)
Im Übrigen wäre – um den Kreis zu schließen – sowas letztlich auch ähnlich mit der Idee des SaltyRTC. Eigentlich müsste es nur auf anderer Abstraktionsebene laufen. Statt den Server zwingend an eine App-Instanz zu binden, müsste sie abstrahiert von allen Clients sein (wenn man will dann Id-gebunden, aber eben nicht Instanz gebunden – aber auch das wäre nicht nötig). Und dann könnte man sie letztlich in den Threema-Server zur Nachrichtenverteilung integrieren. Wohlgemerkt hat der Server dann natürlich nicht die alten Daten gespeichert, aber die Clients könnten hier untereinander (via diesen Server) kommunizieren und ggf. austauschen (was ja auch SaltyRTC machen will) – nur eben, dass Server und feste Appinstanz getrennt sind. Da alle Appinstanzen dann nur Clients wären, könnten sie beliebig offline sein und alles würde trotzdem gehen. Hier war schon das Gespräch von einem Raspi, der als Server fungiert, eigentlich könnte man das gleich bei der Serverseite von Threema integrieren. Dann ginge es auch