Hightower: Diese Frage wird in den FAQ beantwortet: https://threema.ch/de/faq/message_storage
Nachrichten werden maximal 14 Tage gespeichert.
Hightower: Diese Frage wird in den FAQ beantwortet: https://threema.ch/de/faq/message_storage
Nachrichten werden maximal 14 Tage gespeichert.
Ich habe es eben erfolgreich getestet. Ich denke dbrgn, du hast da etwas falsch verstanden.Threema Formatierung:
*fett*
_kursiv_
~durchgestrichen~
Das beispiel oben war selbstverständlich im Original "MIT_ZWEI_UNTERSTRICHEN".
Die aktuelle Version ist übrigens openMittsu_0.9.2plus63-g8407687 - hier sollten die Formatierungen ENDGÜLTIG gefixt sein
Leider nein
Habe dir einen Pull Request geschickt, hoffe der ist nun korrekt.
Ich lese mich gerade durch alle Beiträge. Kannst du mir ein Kompendium zu "github" empfehlen?, bevorzugt auf deutsch.
Es ist nicht ganz leicht zu verstehen was mit fork, merged und pull request gemeint ist.
Das sind alles Begriffe des Versionsverwaltungssystems, Git (https://git-scm.com/). Am besten suchst du via Suchmaschine oder Youtube nach Informationen für Einsteiger.
Änderungen an Gruppen werden als "unsichtbare Nachrichten" an alle Mitglieder versendet. So kann jedes Mitglied den Stand der Gruppe nachvollziehen.
Wenn nun ein Gruppenmitglied seit mehreren Wochen das Smartphone nicht mehr am Netz hatte (oder ein altes Backup einspielt), kann es passieren, dass diese "unsichtbaren Nachrichten" nicht ankommen und der Stand der Gruppe nun nicht mehr synchron ist mit dem Stand des Administrators. Dafür ist das "Gruppe Synchronisieren" Feature gedacht. Damit wird dann der aktuelle Stand der Gruppe wieder an alle Mitglieder gesendet, womit wieder alle up to date sind.
Gibt es eigentlich einen Grund, weshalb gerade dieser Port (5222) verwendet wird und nicht standartmäßig der 443-Port?In letzter Zeit habe ich irgendwie das Gefühl, dass sich jeder Entwickler seine Ports "würfelt".
Port 5222 ist für XMPP reserviert. Adminstratoren erkennen einen solchen Port also als Chat-Port und können ihn entsprechend behandeln.
Port 443 ist für HTTPS gedacht. Definitiv kein "Standard" für Chat-Applikationen mit eigenem TCP basiertem Binär-Protokoll.
Viel besserer Ansatz als eine "Volksverschlüsselung"
Hier übrigens das Whitepaper: https://pep.foundation/docs/pEp-whitepaper.pdf
Es handelt sich hier bisher lediglich um Programmbibliotheken, d.h. Software die als Baustein genutzt wird um andere Software zu schreiben.
Es gibt also keinerlei "Oberfläche" dafür, insofern gibt es also bisher nur etwas auszuprobieren, wenn du Softwareentwickler bist
Beispielcode für die JavaScript Variante gibt es hier: https://github.com/saltyrtc/salty…ster/example.ts
@KL7000F Stimmt, direkt hat das nichts mit RegEx zu tun. Aber der Input wird seit dem Einführen der Formatierungen noch nicht escaped.
Gerade entdeckt, dass openMittsu (auf git!) bereits die Formatierung inne hat. Im direkten Vergleich zur Android-App ist es sehr gut gelungen. Ein erster schneller Test ergab keine Probleme mit Sonderzeichen direkt vor Formatierungszeichen (*, _ und ~).
Dafür gibt's andere Probleme: Wenn ich folgendes sende
> hi
< hello
> what's up?
< the ceiling
Dann sieht das in OpenMittsu wie folgt aus:
RegEx ist schwierig
Alles wunderbar, aber scheinbar nicht bei Windows 10 mobile, da kann man im Store nichts von Threema Work entdecken, im Block werden auch keine Angaben zu den kompatiblen Betriebssystem gemacht, nur bei den MDM/EMM-Systemen wird beschrieben, das Windows 10 mobile nicht tauglich ist
Die Windows Phone Umgebung ist sehr Entwicklerunfreundlich. Microsoft scheint keine klare Strategie zu haben und es gibt viele Bugs und Probleme im System. Und die Nutzerzahlen stehen bei den meisten Apps nicht in einem vernünftigen Verhältnis zum zusätzlichen Entwicklungsaufwand. WP wird wohl aus dem Grund nicht von Work unterstützt.
Schön passend dazu, vor 30 Minuten gefunden: http://www.mcelhearn.com/microsoft-kills-off-windows-phone/
Oops. Habe zwar den ganzen Thread mitgelesen, das aber bereits wieder vergessen
Noch eine kurze Anregung. Wenn der Threema-Server neu gestartet wird (z.B. bei einem Release) verliert openMittsu die Verbindung und zeigt eine Fehlermeldung an.
Da dies aber kein eigentlicher Fehlerzustand darstellt, wäre es möglich einige automatische Reconnect-Versuche (z.B. mit Exponential Backoff) einzubauen und die Verbindung automatisch wieder herzurstellen?
Kann es sein, dass die Main-Klasse fehlt?
Dieses Video zum Thema Massenüberwachung ist auch sehr schön:
Auf Android ist es seit Version 2.7 möglich, Gruppen zu klonen. Wenn der Admin nun seinen Key verliert, kann ein Mitglied die Gruppe klonen, wodurch diese Person zum Admin der neuen Gruppe wird. Das sollte das Problem entschärfen.
Zitat
Dabei wäre es für mich gut, wenn ich die Texte durch Einfügen von Absätzen mittels Enter-Taste lesbarer machen kann. Leider verursacht "Enter" unmittelbar "Send".
Wie in den meisten Programmen kannst du mit "shift+enter" einen Zeilenumbruch einfügen.
Für die ArchLinux Benutzer unter euch: Ich habe mal ein AUR-Package erstellt
https://aur.archlinux.org/packages/openmittsu-git/
Bisher ungetestet, kann natürlich noch Bugs haben.