Chat

In unserer Telegram Gruppe wurde nun schon vermehrt geäußert, dass einige Telegram nicht mehr nutzen wollen.
Es gibt die Möglichkeit mehrere Chat Protokolle mit einem Matrix Server und Bridges zu verbinden. Dadurch kann jede Person den Messenger des geringsten Misstrauens verwenden.

Hinweis: Dies schafft keine Privatsphäre in dem öffentlichen Chatraum des Makerspace, sondern ermöglicht es nur einen Messenger weniger zu benutzen.

Jede Bridge muss eingerichtet werden. Damit wir wissen welche erforderlich sind bitte für den Messenger abstimmen den ihr primär nutzen wollt.
Informationen zum für und wieder der Messenger gibt es Beispielsweise auf dem Datenschutz Blog von Mike Kuketz

Es gibt 26 Messenger zur Auswahl.

Welchen Messenger wollt ihr nutzen? (1-13)
  • Matrix
  • IRC
  • Slack
  • RSS
  • Discord
  • RocketChat
  • iMessage
  • Facebook Messenger
  • Email
  • SMS
  • Mastodon
  • libpurple
  • Skype

0 Teilnehmer

Welchen Messenger wollt ihr nutzen? (14-26)
  • GroupMe
  • WeChat
  • Gitter
  • Tox
  • Twitter
  • Mumble
  • Mattermost
  • Keybase
  • Google Hangouts
  • Instagram
  • Signal
  • Telegram
  • WhatsApp

0 Teilnehmer

So viele Einträge. Threema fehlt leider.

Kommt vielleicht noch, es gibt weitere die sich eine Threema Bridge wünschen

In Paderborn nutzen wir Matrix und Telegram (mit Bridge dazwischen). Das funktioniert ganz gut, aber die meisten Nutzer sind bei Telegram geblieben. Matrix ist nur der Notnagel, damit wir niemanden dazu zwingen sich einen Telegram Account anzulegen. Tatsächlich gibt es einige, die sich konsequent weigern :slight_smile:

Threema könnte schwierig werden, da sie API-Zugriff gerne verkaufen möchten. Sie haben also kein Interesse daran, dass jemand automatisiert Nachrichten verschicken kann - was über eine Matrix-Bridge möglich wäre. Dass sie den Client offengelegt haben, ist schon mal ein gutes Zeichen. Aber es würde mich nicht wundern, wenn sie letztendlich so agieren wie Signal, d.h. im Prinzip ein offener Client aber sie gehen dagegen vor, wenn man deren Server mit anderen Clients nutzt.

Matrix ist für Bridges aber super geeignet, weil die Bridge eine enge Integration mit dem Homeserver eingeht. Dadurch tauchen die Nutzer der anderen Protokolle tatsächlich als richtige Nutzer im Chat auf. Auf der anderen Seite ist die Integration leider nicht so toll. Da kommen alle Nachrichten vom Bot und er schreibt nur den Nutzernamen davor. Zum IRC war die Integration in beiden Richtungen exzellent und es gingen sogar Privatnachrichten (aber wir waren (sind?) bei Hackint und die haben Bridges verboten). Zu Telegram gehen nur Nachrichten in den Gruppen und falls man möchte, dass die Nutzer im Channel auftauchen, muss man manuell einen Bot pro Nutzer anlegen (bzw. das kann der Nutzer selbst tun). Privatnachrichten würden eventuell gehen, wenn unsere Bridge einen richtigen Account hätte, aber die ist nur ein Bot und die dürfen weniger. Ich bin an sich großer Fan von Threema, weil sie beim Schlüsselmanagement das Maximum an Benutzbarkeit herausgeholt haben, ohne dass die Sicherheit leidet. Aber dass sie kein offenes API anbieten, ist überall dort ein Problem, wo man mehr möchte als nur mit eine paar Nutzern von Handy zu Handy reden.

Der Blog von Kuketz ist eine gute Übersicht, aber er hat teilweise ein paar seltsame Annahmen, z.B. dass Metadaten bei einem föderierten System mehr gefährdet sind als bei einem zentralisierten System, bei dem man den Client nicht unter Kontrolle hat. Deshalb schneidet Matrix bei ihm relativ schlecht ab, obwohl es mit eigenem Homeserver für den Verein vermutlich die datensparsamste Option ist.

Falls ihr Fragen habt oder Unterstützung braucht, sagt Bescheid. Ich betreibe einen Matrix Homeserver mit Bridge zu Telegram.

Der Plan für Sonntag ist aktuell synapse per ansible auf einer debian VM zu installieren.

Wenn sich dabei noch Fragen stellen komme ich gerne auf dein Angebot zurück :slight_smile:

Der Matrix Server wurde per ansible eingerichtet und ist unter matrix.makerspace-gt.de erreichbar.
Neue Benutzer müssen explizit angelegt werden, aber das würde ich erst anfangen, wenn die Konfiguration abgeschlossen ist.

Chatten geht nun schon und als nächstes geht es dran die Bridges einzurichten.

Für die Föderation mit anderen Servern braucht es ein .well-known/matrix/ Verzeichnis auf der Haupt-Domain. Dafür wurde in die .htaccess Datei von unserem Wordpress ein redirect eingebaut. Das scheint aber nicht so gut zu sein, da der Inhalt tendenziell überschrieben wird.
Kann ich das auch irgendwie anders machen? @snowball @LeonF?

# BEGIN WordPress
# Die Anweisungen (Zeilen) zwischen „BEGIN WordPress“ und „END WordPress“ sind
# dynamisch generiert und sollten nur über WordPress-Filter geändert werden.
# Alle Änderungen an den Anweisungen zwischen diesen Markierungen werden überschrieben.
<IfModule mod_rewrite.c>
RewriteEngine On

RewriteCond %{REQUEST_URI} .well-known/matrix
RewriteRule ^(.*)$ https://matrix.makerspace-gt.de/$1 [R,L]

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

# END WordPress
1 Like

Schau mal ob es im WordPress eine Möglichkeit gibt. Ansonsten muss es oben drüber. Also über „BEGIN WORDPRESS“

Falls der Vorschlag von @stilkkx funktioniert, nimm den. Ansonsten:

Hast du Zugriff auf die Apache-Config? Das wäre eine Option.

Die andere wäre, dass du den .well-known Ordner anlegst und darin eine .htaccess. Die anderen Regeln sehen aber so aus, als würden sie alles an index.php weiterleiten - dann geht das nicht.

In dem Fall gäbe es noch die Option, das in einen /static Ordner von Wordpress zu legen (wie auch immer der bei denen heißt) und zu hoffen, dass der passend gemappt ist. Da wird dann kein .htaccess funktionieren, aber ich denke, die .well-known Dateien von Matrix werden sich nicht ändern, d.h. kannst du rüber kopieren. Allerdings macht es auf den ersten Blick den Eindruck, dass die statischen Wordpress Dinge unter /wp-includes und /wp-content liegen, d.h. vermutlich kannst du da nichts so ablegen, dass es unter /.well-known auftaucht.

Ansonsten kannst du auch einen ähnlichen gleichen Effekt über einen SRV Record im DNS erreichen statt über .well-known. Für den Minecraft Server hattet ihr das auch gemacht/überlegt, richtig? Ich bin mir nur gerade nicht sicher, ob dass Implikationen für das Zertifikat hat. Wenn du .well-known nicht mappen kannst, wird auch Let’s Encrypt nur für die Sub-Domain funktionieren.

Bezüglich SRV: Ich habe mal in die Doku geschaut. Die verstehe ich so, dass du bei SRV ein Zertifikat für die Hauptdomain brauchst und bei .well-known nicht. Das ist aus Sicherheits-Gesichtspunkten sehr sinnvoll (solange man nicht überall DNSSEC hat). Das heißt aber leider, dass du .well-known brauchst - entweder für Matrix oder für Let’s Encrypt… SRV ist keine Option.

siehe https://matrix.org/docs/spec/server_server/latest

Die Schritte zum Aufsetzen fasse ich nun in der DOCUMENTATION.md.
Ziel ist es am Ende den Server noch einmal Platt zu machen und komplett neu via ansible aufzusetzen.

Muss dann darüber auch noch

<IfModule mod_rewrite.c>
RewriteEngine On

</IfModule>

?

Leider nein, das Wordpress läuft bei unserem Webhoster.