Mit MS Teams musste/durfte ich bisher noch nicht arbeiten. Alle deine genannten Aufgaben (Dateiablage, Wiki, Planner) nutzen wir aber auch. Ebenso wie das oben bereits genannte Mail, Rocket und BBB als Insellösungen. Mangels Erfahrung weiß ich nicht, ob ich so viel effizienter arbeiten würde, wenn alles integriert wäre.
Öffentliche Matrix Server in Deutschland
Anmeldungsdatum: Beiträge: 5557 Wohnort: Freiburg i. Brsg. |
|
(Themenstarter)
Anmeldungsdatum: Beiträge: 620 |
[...]
Das kann ich auf eine Weise beantworten, dass mir ein Informatiker versucht hat das zu erklären. Anscheinend ist xmpp eigentlich ein besseres Chatprotokoll. Die Verbindung kann offen bleiben und somit so eine Art Push erzeugen, auch ohne Google-Dienste/Apple Push. Matrix baut sehr auf Webtechnologien auf, also http usw. für Sofort-Nachrichten im Sinne des Wortes (Push) braucht es eben die genannten Dienste. Wenn es eben nicht mehrfach pro Sekunde nach neuen Nachrichten schauen soll, und damit deinen Akku leer zieht. Das war jetzt aber wirklich nur aus dem Hinterkopf, das kann hier sicher noch jemand besser und aus wirklichem Wissen heraus erklären. Kennt denn jemand die Leute hinter oder generell die Dienste von Privacytools? https://privacytools.it-sec.rocks/ Zur restlichen Diskussion: Ich glaube ja immer noch, dass gerade im wirtschaftlichen Sinne eine wohlformulierte E-Mail (Anruf/Brief) nachhaltiger ist, als wenn ich schnell mal ein paar Nachrichten per App tippe und immer wieder korrigieren muss. Damit unterstelle ich, dass ich bei einer Mail etwas länger darüber nachdenke, was ich schreiben möchte - ohne zu wissen, ob das so ist. Grüße Thoys |
Anmeldungsdatum: Beiträge: 4101 |
Das wurde jetzt ein längerer Text, aber Push ist leider nicht ganz so einfach. Ich hoffe ich konnte das trotzdem halbwegs verständlich halten:
Puh, da müsste man jetzt den Informatiker fragen der dir das erklärt hat. Für XMPP gibt es mindestens eine Implementierung für Push-Benachrichtigungen, soweit weiß ich das auch gerade noch. Das Problem ist aber nicht Push an sich, das Problem sind mobile Endgeräte. Wie Push funktioniert: Push funktioniert in der Regel so, dass man eine Verbindung zum Server aufbaut, und diese offen hält. Der Server kann darüber dann eine Nachricht an den Client schicken. Das geht sowohl via HTTP (HTTP-Server-Push), als auch über (IMHO bessere) Protokolle wie Websocket. Damit das funktioniert muss aber auch die offene Verbindung regelmäßig kurz auf ihre Funktion geprüft, und ggf. neu aufgebaut werden. Nicht, dass der Server die ganze Zeit dem Client Nachrichten schickt, und dabei kommen die gar nicht an. Der Begriff den ich dafür kenne ist Heartbeart (weil es eben wie ein „Herzschlag“ für die Verbindung ist), aber ich weiß nicht ob der Begriff aktuell dafür tatsächlich verwendet wird. Das Tl;dr hier ist, dass das Problem der Push-Benachrichtigungen bereits gelöst ist, sofern es sich um normale Rechner handelt. Das Problem mobiler Endgeräte: Auf mobilen Endgeräten hat man aber das Problem, dass man den Akku möglichst wenig belasten will. Daher legen die üblichen Betriebssysteme Apps im Hintergrund in den Schlafzustand und kappen somit effektiv die Verbindung. Bei Apples iOS war von Anfang an die Philosophie, dass Apps im Hintergrund nicht laufen dürfen, und man konnte lediglich Apples eigenen Push-Nachrichtendienst verwenden. Das erklärt übrigens unter anderem die guten Akkulaufzeiten von iPhones. D.h. HTTP-Server-Push und Websocket gingen gar nicht. Ob das noch immer so ist weiß ich nicht, dafür habe ich von Apple Hard- und Software zu wenig Ahnung. Bei Android war es anders, hier hatte man anfangs erlaubt, dass Dienste im Hintergrund uneingeschränkt laufen dürfen, mittlerweile hat man aber auch das stark eingeschränkt (wenn dich das interessiert such mal nach "Android Doze Modus"). Grund war unter anderem die Akkulaufzeit. Mittlerweile ist auch hier der Standard, dass man Firebase Cloud Messaging nutzt (früher Google Cloud Messaging), was einfach nur der Push-Benachrichtigungsdienst für Android ist (von Google). Vorteil/Nachteil von zentralisierten Push-Diensten: Der Vorteil des Ganzen ist, dass alle Benachrichtigungen über ein System laufen, und das Betriebssystem nur eine Verbindung offen halten muss damit das funktioniert. Die ist auch unabhängig von Apps, und muss außer Nachrichten empfangen und dann an die richtige App zustellen auch nicht viel können. D.h. man kann das sehr leichtgewichtig bauen, und auch die Verwendung ist relativ einfach (zumindest für FCM/GCM). Gibt auch eine FOSS-Implementierung von FCM/GCM namens MicroG. Problem dabei ist aber, dass eben *alle* Nachrichten über die Server von Apple und Google laufen. Das stellt ein enormes Privatsphäre- bzw. Datenschutzproblem dar. Messenger wie Signal lösen das, indem Push eben wirklich nur zur Info genutzt wird, dass eine Nachricht geschickt wurde. Die Push-Nachricht selbst enthält aber keine weiteren Daten (kein Absender, keine verschlüsselte Nachricht, nichts. Nur die Info "Hey Signal, verbinde dich bitte mal mit dem Server, da liegt für dich mindestens eine neue Nachricht"). Damit haben Apple bzw. Google maximal die Info, dass du eine Nachricht bekommen hast, aber keine weiteren Metadaten dazu. Das machen aber die wenigsten Apps so, die meisten Apps schicken einfach die komplette Nachricht unverschlüsselt mit der Push-Benachrichtigung mit. Und das ist wiederum ein gravierendes Problem, denn damit können Apple und Google im Prinzip deine ganze private Kommunikation mitlesen. Jedenfalls, wenn die Push-Benachrichtigung dann am mobilen Endgerät angekommen ist weckt das Betriebssystem die passende App kurz aus dem Standby auf (wobei es von den Einstellungen des Betriebssystems abhängt wann genau, wenn du dein Android-Phone bspw. seit zwei Stunden nicht bewegt hast kann es [wenn ich mich nicht irre] bis zu 15 Minuten dauern bis die App tatsächlich aufgeweckt wird, wenn du es gerade in der Hand hältst und den Bildschirm vor wenigen Sekunden erst an hattest geschieht das sofort). Die App lädt daraufhin die Nachricht, checkt evtl. kurz noch was der Server dazu sagt (also kurzer Verbindungsaufbau zum Server, paar Daten holen, fertig), und generiert daraufhin die Nachricht die dir anzeigt dass du eine Nachricht bekommen hast (inklusive Ton und Vibration, je nachdem, wie dein Handy und die App konfiguriert sind). Soweit würde das auch alles wunderbar funktionieren, wenn die Hersteller von Smartphones das auch alles so berücksichtigen würden. Leider gibt es viele Hersteller die ein eigenes "Akkuschonprogramm" entwickeln, was dann verhindert, dass die App tatsächlich aufwacht. D.h. die Push-Nachricht kam an, die App wird aber nicht aus dem Standby geholt, und da diese die Benachrichtigung generieren sollte bekommt man dann teilweise keine Benachrichtigungen. Das verlängert zwar die Akkulaufzeit, ist aber enorm frustrierend für Entwickler. Gerade Huwaei, Honor und Samsung bereiten hier immer wieder Probleme und man kann als Entwickler einfach nichts dagegen machen. Tl;dr: Das Tl;dr ist also:
Wie Matrix/Element das handhabt: Matrix bzw. Element verwendet (übrigens auch wie viele andere Apps) einen hybriden Ansatz. Wenn du Element nutzt, und ein Konto bei Matrix.org hast, wird Apples bzw. Googles Push-Benachrichtigungsdienst verwendet (ähnlich wie bei Signal auch nur die Nachricht, dass etwas da ist, aber ohne private Daten, die muss sich der Client dann selbst vom Server holen nachdem das Betriebssystem die App aus dem Standby geholt hat). Wenn Push nicht verfügbar ist läuft im Hintergrund automatisch ein Dienst der auf regelmäßig den Server nach neuen Nachrichten fragt. Und natürlich kann man auch ein eigenes Push-Gateway betreiben, wenn man einen eigenen Matrix-Server betreibt. |