XMPP-Server: Unterschied zwischen den Versionen
Geierb (Diskussion | Beiträge) |
Bg3992 (Diskussion | Beiträge) Keine Bearbeitungszusammenfassung |
||
(25 dazwischenliegende Versionen von 3 Benutzern werden nicht angezeigt) | |||
Zeile 7: | Zeile 7: | ||
* [[Benutzer:Geierb|Geierb]] |
* [[Benutzer:Geierb|Geierb]] |
||
==Benutzerzugänge== |
== Benutzerzugänge == |
||
Informationen für Anwender finden sich hier: [https://xmpp.bytewerk.org/ https://xmpp.bytewerk.org/] |
|||
=== <Bingo-Benutzername>@bingo-ev.de === |
|||
Jedes Bingo-Mitglied hat automatisch einen Account. |
Jedes Bingo-Mitglied hat automatisch einen Account. |
||
Zeile 17: | Zeile 13: | ||
Die JID ist identisch zur Bingo-E-Mail-Adresse, das Passwort ist das Bingo-E-Mail-Passwort. |
Die JID ist identisch zur Bingo-E-Mail-Adresse, das Passwort ist das Bingo-E-Mail-Passwort. |
||
E-Mail-Aliase der Domains @bingo-ev.de und @bytewerk.org können ebenfalls als JIDs verwendet werden. |
|||
Das Passwort kann nicht im XMPP-Client geändert werden, da zur Authentifizierung der Bingo-Mailserver benutzt wird. |
|||
Informationen für Anwender finden sich hier: https://xmpp.bytewerk.org/ |
|||
=== <wunschname>@bytewerk.org === |
|||
== Chaträume == |
|||
Accounts werden auf Zuruf erstellt (siehe oben "Verantwortlich"). Das Passwort kann im XMPP-Client geändert werden. |
|||
=== Grunsätzlich === |
|||
Jeder kann nach Belieben Chaträume anlegen. |
|||
=== Automatisch angelegte Chaträume === |
|||
Zusätzlich kann jeder vorhandene Benutzer '''"Invite"-Codes''' erstellen und diesen anderen Personen zuschicken, die sich dann damit einen @bytewerk.org-Account anlegen können: |
|||
Folgende Chaträume werden automatisch angelegt: |
|||
# In [https://xmpp.bytewerk.org/conversejs-bytewerk Converse.js] anmelden |
|||
* [xmpp:bingo-users@conference.bingo-ev.de bingo-users@conference.bingo-ev.de] [https://conference.bingo-ev.de/muc_badge/bingo-users@conference.bingo-ev.de] |
|||
# Links oben auf das Zahnrad klicken |
|||
* [xmpp:bytewerk@conference.bytewerk.org bytewerk@conference.bytewerk.org] [https://conference.bytewerk.org/muc_badge/bytewerk@conference.bytewerk.org] |
|||
# Auf "Befehle" klicken |
|||
# Als Instanz "bytewerk.org" eingeben |
|||
=== Badges === |
|||
# "Verfügbare Befehle auflisten" klicken |
|||
Badges für Chaträume können über https://conference.<DOMAIN>/muc_badge/<MUC-JID> abgerufen werden. |
|||
# Auf "Create new contact invite" klicken |
|||
# Die angezeigte Adresse zur "Invite web page" kopieren und der Einzuladenden zukommen lassen. Der Link ist eine Woche lang gültig. |
|||
Beispiele: |
|||
* Das Badge für [xmpp:bytewerk@conference.bytewerk.org bytewerk@conference.bytewerk.org] kann über die URL https://conference.bytewerk.org/muc_badge/bytewerk@conference.bytewerk.org abgerufen werden und sieht so aus: [[Datei:MUC badge bytewerk.png|frameless|caption]] |
|||
* Das Badge für [xmpp:bingo-users@conference.bingo-ev.de bingo-users@conference.bingo-ev.de] kann über die URL https://conference.bingo-ev.de/muc_badge/bingo-users@conference.bingo-ev.de abgerufen werden und sieht so aus: [[Datei:MUC badge bingo-users.png|frameless|caption]] |
|||
=== IRC-Chat === |
|||
Zum Betreten von IRC-Chats einfach einen neuen Chat mit dem Muster '''#CHANNEL%SERVER@biboumi.bytewerk.org''' anlegen. |
|||
Beispiel: |
|||
Um den Channel '''#pypy''' auf '''irc.libera.chat''' zu besuchen, einen neuen Chat mit der Adresse '''#pypy%irc.libera.chat@biboumi.bytewerk.org''' starten. |
|||
Im XMPP-Client werden dann automatisch der Channel und der IRC-Server als Gesprächspartner hinzugefügt. |
|||
Sollten die Nachrichten des IRC-Servers stören: Diesen einfach als Gesprächspartner blockieren. |
|||
== XMPP-Clients == |
== XMPP-Clients == |
||
Zeile 48: | Zeile 59: | ||
== Unterstützte Funktionen == |
== Unterstützte Funktionen == |
||
=== Übersicht === |
|||
* Gruppen |
|||
* Gruppen (öffentlich/privat/mit Einladung, moderiert/unmoderiert) |
|||
* Audio- und Videotelefonie |
* Audio- und Videotelefonie |
||
* Sprach- und Videonachrichten |
|||
* Ende-zu-Ende-Verschlüsselung |
* Ende-zu-Ende-Verschlüsselung |
||
* Dateiup- und Download (wird auch für Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße derzeit limitiert auf 100 MByte. |
* Dateiup- und Download (wird auch für Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße pro Upload derzeit limitiert auf 100 MByte. |
||
* Gleichzeitiges Verwenden mehrerer Clients |
* Gleichzeitiges Verwenden mehrerer Clients |
||
* Push |
|||
* IRC |
|||
[https://compliance.conversations.im/live/bytewerk.org/ 100% Compliance] zu Conversations |
|||
Dateien und Chatverläufe werden nach einem Monat vom Server gelöscht. |
Dateien und Chatverläufe werden nach einem Monat vom Server gelöscht. |
||
Zeile 58: | Zeile 76: | ||
Die oben genannten Funktionen stehen nicht immer zur Verfügung, weil sich die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients ergeben :) |
Die oben genannten Funktionen stehen nicht immer zur Verfügung, weil sich die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients ergeben :) |
||
Beispiel: Ist mein Gesprächspartner ein Shellskript, das mir eine Nachricht schickt wenn die Waschmaschine fertig ist, werde ich |
Beispiel: Ist mein Gesprächspartner ein Shellskript, das mir eine Nachricht schickt wenn die Waschmaschine fertig ist, dann werde ich mit diesem kein Videotelefonat führen können, selbst wenn es mein XMPP-Client und der Server unterstützt. |
||
Wichtig bei der '''gleichzeitigen Verwendung von mehreren Clients''': Eine Nachricht gilt als zugestellt, wenn sie an EINEM Client des Empfängers angekommen ist. Das kann bei wackeliger Internetverbindung dazu führen, dass Nachrichten scheinbar nicht zugestellt wurden - sie landen dann nur bei dem Gerät, dass gerade online ist. Zwar prüfen die meisten XMPP-Clients beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten eingetroffen sind, aber eben nicht alle. |
|||
Ebenso ist undefiniert, was passiert, wenn ein Videoanruf gestartet werden soll, der Gesprächspartner aber mit mehreren Clients online ist, von denen nicht alle Videotelefonie unterstützen. |
Ebenso ist undefiniert, was passiert, wenn ein Videoanruf gestartet werden soll, der Gesprächspartner aber mit mehreren Clients online ist, von denen nicht alle Videotelefonie unterstützen. |
||
Threema, Whatsapp usw. |
Threema, Whatsapp usw. machen es sich einfach: Die verbieten schlicht die parallele Nutzung sowie Fremd-Clients. |
||
== Fortschritt == |
== Fortschritt == |
||
Zeile 69: | Zeile 87: | ||
;2021-02: Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert |
;2021-02: Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert |
||
;2021-08: Serverkonfiguration auf Ansible umgestellt, dabei kleine Fehler behoben, neue Funktionen hinzugefügt, Conversejs aktualisiert. |
;2021-08: Serverkonfiguration auf Ansible umgestellt, dabei kleine Fehler behoben, neue Funktionen hinzugefügt, Conversejs aktualisiert. |
||
;2022-08: Push-Services für Monal IM aktiviert |
|||
;2022-09: IRC-Transport |
|||
== Implementierung == |
|||
=== Software === |
|||
Auf der VM '''xmpp.bytewerk.org''' läuft: |
|||
* [https://prosody.im/ Prosody]: XMPP-Server |
|||
* [https://www.postgresql.org PostgreSQL]: Datenbank für Benutzer, Kontakte, Gruppen und Chats |
|||
* [https://github.com/coturn/coturn Coturn]: TURN und STUN (für Jingle/WebRTC benötigt, d.h. Audio-/Videotelefonie sowie Dateiübertragung von Client zu Client) |
|||
* [https://github.com/conversejs/converse.js ConverseJS]: XMPP-Webclient, mit einigen [https://github.com/conversejs/community-plugins Community-Plugins] |
|||
* [https://httpd.apache.org/ Apache2] mit mod_php: HTTPS-Reverse-Proxy für File-Up- und -Downloads, ''.well-known''-URLs, BOSH und Websocket, Bereitstellung von ConverseJS. PHP wird für das "share_v2.php"-Skript benötigt, das sich um Datei-Up- und Downloads kümmert. |
|||
* [https://github.com/DigitaleGesellschaft/Anonip Anonip]: Wird zum Logging in Apache2 benutzt um in den Access-Logs die letzten Stellen der IP-Adressen auf 0 setzen. Liegt unter ''/usr/local/Anonip.git'' |
|||
* [https://certbot.eff.org Certbot]: Für TLS-Zertifikatsaktualisierung |
|||
* Crond: Um Certbot wöchentlich aufzurufen und um täglich das Fileupload-Verzeichnis aufzuräumen |
|||
=== DNS === |
|||
XMPP-Server und -Clients nutzen SRV-Records, um anhand der JID-Domäne eines Nutzer den Server, die Components und deren Ports zu herauszufinden. |
|||
Die A/AAAA-Einträge werden gebraucht, um für die SRV-Records die TLS-Zertifikate zu erstellen. |
|||
==== Auszug aus dem Zonefile von bytewerk.org ==== |
|||
<pre> |
|||
xmpp.bytewerk.org. 300 IN A 94.142.219.72 # Prosody-Server, Coturn-Server, Apache2 |
|||
xmpp.bytewerk.org. 300 IN AAAA 2a02:868:15::72:1 |
|||
conference.bytewerk.org. 300 IN A 94.142.219.72 # MUC-Component, Apache2 |
|||
conference.bytewerk.org. 300 IN AAAA 2a02:868:15::72:1 |
|||
proxy.bytewerk.org. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2 |
|||
proxy.bytewerk.org. 300 IN AAAA 2a02:868:15::72:1 |
|||
upload.bytewerk.org. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2 |
|||
upload.bytewerk.org. 300 IN AAAA 2a02:868:15::72:1 |
|||
pubsub.bytewerk.org. 300 IN A 94.142.219.72 # PubSub-Component, Apache2 |
|||
pubsub.bytewerk.org. 300 IN AAAA 2a02:868:15::72:1 |
|||
_xmpp-client._tcp.bytewerk.org. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S |
|||
_xmpps-client._tcp.bytewerk.org. 300 IN SRV 0 5 5223 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S Legacy SSL auf Port 5223 |
|||
_xmpp-server._tcp.bytewerk.org. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # VirtualHost XMPP-Server, S2S |
|||
_xmpp-server._tcp.conference.bytewerk.org. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # MUC-Component, S2S |
|||
_xmpp-server._tcp.proxy.bytewerk.org. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # Proxy65-Component, S2S |
|||
_xmpp-server._tcp.pubsub.bytewerk.org. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # PubSub-Component, S2S |
|||
_xmppconnect.bytewerk.org. 300 IN TXT "_xmpp-client-xbosh=https://xmpp.bytewerk.org/http-bind" # BOSH |
|||
_xmppconnect.bytewerk.org. 300 IN TXT "_xmpp-client-websocket=wss://xmpp.bytewerk.org/xmpp-websocket" # Websocket |
|||
</pre> |
|||
==== Auszug aus dem Zonefile von bingo-ev.de ==== |
|||
<pre> |
|||
conference.bingo-ev.de. 300 IN A 94.142.219.72 # MUC-Component, Apache2 |
|||
conference.bingo-ev.de. 300 IN AAAA 2a02:868:15::72:1 |
|||
proxy65.bingo-ev.de. 300 IN A 94.142.219.72 # Proxy65-Component, Apache2 ("proxy.bingo-ev.de" ist bereits belegt) |
|||
proxy65.bingo-ev.de. 300 IN AAAA 2a02:868:15::72:1 |
|||
upload.bingo-ev.de. 300 IN A 94.142.219.72 # HTTP-Fileupload, Apache2 |
|||
upload.bingo-ev.de. 300 IN AAAA 2a02:868:15::72:1 |
|||
pubsub.bingo-ev.de. 300 IN A 94.142.219.72 # PubSub-Component, Apache2 |
|||
pubsub.bingo-ev.de. 300 IN AAAA 2a02:868:15::72:1 |
|||
_xmpp-client._tcp.bingo-ev.de. 300 IN SRV 0 5 5222 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S |
|||
_xmpps-client._tcp.bingo-ev.de. 300 IN SRV 0 5 5225 xmpp.bytewerk.org. # VirtualHost XMPP-Server, C2S Legacy SSL auf Port 5225 |
|||
_xmpp-server._tcp.bingo-ev.de. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # VirtualHost XMPP-Server, S2S |
|||
_xmpp-server._tcp.conference.bingo-ev.de. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # MUC-Component, S2S |
|||
_xmpp-server._tcp.proxy65.bingo-ev.de. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # Proxy65-Component, S2S |
|||
_xmpp-server._tcp.pubsub.bingo-ev.de. 300 IN SRV 0 5 5269 xmpp.bytewerk.org. # PubSub-Component, S2S |
|||
_xmppconnect.bingo-ev.de. 300 IN TXT "_xmpp-client-xbosh=https://xmpp.bytewerk.org/http-bind" # BOSH |
|||
_xmppconnect.bingo-ev.de. 300 IN TXT "_xmpp-client-websocket=wss://xmpp.bytewerk.org/xmpp-websocket" # Websocket |
|||
</pre> |
|||
=== Zertifikate === |
|||
'''''Prosody''''' benötigt Zertifikate für ALLE beteiligten Domains, also auch von bytewerk.org und bingo-ev.de. Components ohne Zertifikat funktionieren nicht mit externen Usern. |
|||
Mit "prosodyct check" kann geprüft werden ob alle Zertikate passend zu den DNS-Einträgen und zu den Components vorhanden sind (Ausnahme: Legacy-SSL). |
|||
Für Feinheiten lohnt sich ein Blick in "/var/log/prosody/prosody.err", besonders mit eingeschaltetem "debug"-Loglevel. |
|||
'''''Coturn''''' benötigt nur das Zertifikat von "xmpp.bytewerk.org" |
|||
'''''Apache2''''' braucht grundsätzlich nur Zertifikate für "xmpp.bytewerk.org", "upload.bytewerk.org" und "upload.bingo-ev.de". |
|||
Um die Zertifikate, die von Prosody benötigt werden, mit Certbot zu erstellen, gibt's diese vHosts: |
|||
* xmpp.bytewerk.org |
|||
* conference.bytewerk.org, pubsub.bytewerk.org, proxy.bytewerk.org, upload.bytewerk.org |
|||
* conference.bingo-ev.de, pubsub.bingo-ev.de, proxy65.bingo-ev.de, upload.bingo-ev.de |
|||
==== TLS-Zertifikate für bytewerk.org und bingo-ev.de ==== |
|||
Die Zertifikate für bytewerk.org und bino-ev.de wird nicht auf der VM erstellt sondern müssen auf den XMPP-Server kopiert und User "prosody" übereignet werden. |
|||
Danach muss Prosody mit "prosodyctl reload" neu geladen werden. |
|||
* bytewerk.org: |
|||
** ''/etc/prosody/certs/bytewerk.org/privkey.pem'' |
|||
** ''/etc/prosody/certs/bytewerk.org/fullchain.pem'' |
|||
* bingo-ev.de: |
|||
** ''/etc/prosody/certs/bingo-ev.de/privkey.pem'' |
|||
** ''/etc/prosody/certs/bingo-ev.de/fullchain.pem'' |
|||
==== Alle anderen Zertifikate ==== |
|||
Alle Zertifikate außer dem von bytewerk.org und bingo-ev.de werden von LetsEncrypt-Certbot erstellt und liegen unter ''/etc/letsencrypt''. |
|||
Das Renewal wird per wöchentlichem Cronjob von root mit ''/usr/bin/certbot renew'' durchgeführt. |
|||
Zertifikate: |
|||
* xmpp.bytewerk.org |
|||
* conference.bytewerk.org, pubsub.bytewerk.org, proxy.bytewerk.org, upload.bytewerk.org |
|||
* conference.bingo-ev.de, pubsub.bingo-ev.de, proxy65.bingo-ev.de, upload.bingo-ev.de |
|||
Nach einem erfolgten Renewal führt Certbot die Post-Renewal-Hook-Skripte in ''/etc/letsencrypt/renewal-hooks/post/'' aus: |
|||
* ''apache2.sh'': Lädt Apache2 neu |
|||
* ''coturn.sh'': Kopiert die Zertifikate nach ''/etc/coturn/certs/'', passt die Rechte an und startet Coturn neu |
|||
* ''prosody.sh'': Kopiert die Zertifikate nach ''/etc/prosody/certs/'', passt die Rechte an und lädt Prosody neu |
|||
=== Konfiguration Prosody === |
|||
Kommentierte Konfigurationsdatei "/etc/prosody/prosody.cfg.lua" |
|||
Da beim Prosody-Paket von OpenSuse eine Menge benötigter Module fehlen, wurden die Module direkt aus dem Prosody-Mercuriual-Repository nach "/usr/local/lib/prosody-modules/" geklont |
|||
Zum Aktualisieren einfach "/usr/local/sbin/update-prosody-modules.sh" ausführen und Prosody mit "prosodyctl reload" neu laden. |
|||
=== Konfiguration Apache2 === |
|||
In ''/etc/apache2/vhosts.d/01-set-servername.conf'': Hostname auf xmpp.bytewerk.org setzen |
|||
Diese vHosts wurden in ''/etc/apache2/vhosts.d/'' angelegt: |
|||
* conference.bytewerk.org.conf, conference.bingo-ev.de.conf: Nur Platzhalter für Certbot |
|||
* proxy.bytewerk.org.conf, proxy65.bingo-ev.de.conf: Nur Platzhalter Certbot |
|||
* pubsub.bytewerk.org.conf, pubsub.bingo-ev.de.conf: Nur Platzhalter Certbot |
|||
* upload.bytewerk.org.conf, upload.bingo-ev.de.conf: Fileupload per mod_http_upload_external + share_v2.php |
|||
* xmpp.bytewerk.org.conf: Reverse-Proxy für BOSH, Websocket und für die von mod_http_altconnect erstellte .well-known-URIs |
|||
Alle vHosts außer upload.bytewerk.org leiten auf https://jabber.bytwerk.org um. |
|||
=== Konfiguration Coturn === |
|||
Kommentierte Konfigurationsdatei "/etc/coturn/turnserver.conf" |
|||
=== Fileupload === |
|||
Der in Prosody eingebaute HTTP-Server unterstützt nur den Upload von Dateien <= 10 MByte und funktioniert nicht mit einigen iOS-Clients (z.B. Monal, Siskin). |
|||
Um diese Probleme zu umgehen wird das von Prosody empfohlene Modul "mod_http_upload_external" verwendet. |
|||
Bei dem Modul funktioniert der Dateiup- und Download über das mitgelieferte PHP-Skript "share_v2.php", das unter dem Apache-vHost "https://upload.bytewerk.org/share_v2.php" (bzw. https://upload.bingo-ev.org/share_v2.php) eingebunden ist und hochgeladene Dateien unter "/srv/var/prosody-upload/<DOMAIN>/" abspeichert. |
|||
Dateien, die älter als ein Monat sind, werden per täglichem Cronjob von root gelöscht. |
|||
=== well-known-URLs === |
|||
Um XEP-0156 ("Discovering Alternative XMPP Connection Methods") zu erfüllen, müssen die Webserver von bytewerk.org und bingo-ev.de per Reverse Proxy folgende URL vom XMPP-Server durchreichen. Es reicht wenn die URLs über HTTPS erreichbar sind: |
|||
* ''xmpp.bytewerk.org/.well-known/host-meta'' unter: |
|||
** https://bytewerk.org/.well-known/host-meta |
|||
** https://bingo-ev.de/.well-known/host-meta |
|||
* ''xmpp.bytewerk.org/.well-known/host-meta.json'' unter: |
|||
** https://bytewerk.org/.well-known/host-meta.json |
|||
** https://bingo-ev.de/.well-known/host-meta.json |
|||
Ein einfacher Redirect funktioniert nicht, da dieser die von Prosody gesetzten HTTP-CORS-Header zurücksetzt. |
|||
==Probleme/ToDo== |
|||
siehe https://git.bingo-ev.de/geierb/bytewerk-xmpp-server/-/issues |
|||
=== Routing === |
|||
Stand 02.09.2021 gibt's ohne folgende Änderungen Routingprobleme mit IPv6: |
|||
Route Announcements auf dem Interface net-nat ignorieren: |
|||
In ''/etc/sysctl.d/ipv6-ignore-ra.conf'': |
|||
<pre> |
|||
net.ipv6.conf.net-nat.accept_ra=0 |
|||
net.ipv6.conf.net-nat.autoconf=0 |
|||
</pre> |
|||
In ''/sysconfig/network/routes'' Default-Route für IPv4 setzen: |
|||
<pre> |
|||
# target via netmask interface |
|||
default 94.142.219.94 0.0.0.0 net-public |
|||
</pre> |
|||
In ''/etc/iproute2/rt_tables'' neue Routingtabelle namens "public" anlegen: |
|||
<pre> |
|||
# |
|||
# reserved values |
|||
# |
|||
255 local |
|||
254 main |
|||
253 default |
|||
0 unspec |
|||
# |
|||
# local |
|||
# |
|||
#1 inr.ruhep |
|||
200 public |
|||
</pre> |
|||
Verbindungen zur öffentliche IPv6-Adresse über diese Route laufen lassen. Dazu in ''/etc/sysconfig/network/ifrule-net-public'': |
|||
<pre> |
|||
ipv6 from 2a02:868:15:72::1/64 table public |
|||
</pre> |
|||
==Files== |
==Files== |
||
Das Ansible |
Das Ansible-Playbook samt Inventory befinden sich hier: https://git.bingo-ev.de/infrastructure/xmpp |
||
[[Category:Projekt]] |
[[Category:Projekt]] |
Aktuelle Version vom 31. Januar 2024, 20:41 Uhr
Ziel
Konkurrenzfähiger, zuverlässiger, selbst betriebener, erweiterbarer Instant Messenger mit allen derzeitig üblichen Funktionen.
Verantwortlich
Benutzerzugänge
Jedes Bingo-Mitglied hat automatisch einen Account.
Die JID ist identisch zur Bingo-E-Mail-Adresse, das Passwort ist das Bingo-E-Mail-Passwort.
E-Mail-Aliase der Domains @bingo-ev.de und @bytewerk.org können ebenfalls als JIDs verwendet werden.
Informationen für Anwender finden sich hier: https://xmpp.bytewerk.org/
Chaträume
Grunsätzlich
Jeder kann nach Belieben Chaträume anlegen.
Automatisch angelegte Chaträume
Folgende Chaträume werden automatisch angelegt:
Badges
Badges für Chaträume können über https://conference.<DOMAIN>/muc_badge/<MUC-JID> abgerufen werden.
Beispiele:
- Das Badge für bytewerk@conference.bytewerk.org kann über die URL https://conference.bytewerk.org/muc_badge/bytewerk@conference.bytewerk.org abgerufen werden und sieht so aus:
- Das Badge für bingo-users@conference.bingo-ev.de kann über die URL https://conference.bingo-ev.de/muc_badge/bingo-users@conference.bingo-ev.de abgerufen werden und sieht so aus:
IRC-Chat
Zum Betreten von IRC-Chats einfach einen neuen Chat mit dem Muster #CHANNEL%SERVER@biboumi.bytewerk.org anlegen.
Beispiel:
Um den Channel #pypy auf irc.libera.chat zu besuchen, einen neuen Chat mit der Adresse #pypy%irc.libera.chat@biboumi.bytewerk.org starten.
Im XMPP-Client werden dann automatisch der Channel und der IRC-Server als Gesprächspartner hinzugefügt. Sollten die Nachrichten des IRC-Servers stören: Diesen einfach als Gesprächspartner blockieren.
XMPP-Clients
Es kann jeder XMPP-Client verwendet werden. Empfehlenswerte Clients für Android, iOS, Linux, Windows und MacOS sind auf https://xmpp.bytewerk.org/ aufgeführt.
Webclients
Auf xmpp.bytewerk.org ist Converse.js installiert:
Grundsätzlich kann sich jeder XMPP-Nutzer an jedem XMPP-Webclient anmelden. Je nach URL werden nur ein paar Voreinstellungen passend zur Domain gesetzt um die Benutzung von Converse.js zu erleichtern.
Sonstige
In Thunderbird ist ein sehr einfacher Client (nur Text) integriert ("Konten" -> "Chat-Konto" hinzufügen).
Für Nextcloud gibt es mit der ojsxc-App einen sehr gut ausgestatteten webbasierten Client.
Unterstützte Funktionen
Übersicht
- Gruppen (öffentlich/privat/mit Einladung, moderiert/unmoderiert)
- Audio- und Videotelefonie
- Sprach- und Videonachrichten
- Ende-zu-Ende-Verschlüsselung
- Dateiup- und Download (wird auch für Fotos, Sprach- und Videonachrichten verwendet) - Dateigröße pro Upload derzeit limitiert auf 100 MByte.
- Gleichzeitiges Verwenden mehrerer Clients
- Push
- IRC
100% Compliance zu Conversations
Dateien und Chatverläufe werden nach einem Monat vom Server gelöscht.
Die Kosten der Freiheit
Die oben genannten Funktionen stehen nicht immer zur Verfügung, weil sich die bei der Kommunikation mit einem bestimmten Gesprächspartner zur Verfügung stehenden Funktionen aus der Schnittmenge des Funktionsumfangs der beteiligten XMPP-Server und der XMPP-Clients ergeben :)
Beispiel: Ist mein Gesprächspartner ein Shellskript, das mir eine Nachricht schickt wenn die Waschmaschine fertig ist, dann werde ich mit diesem kein Videotelefonat führen können, selbst wenn es mein XMPP-Client und der Server unterstützt.
Wichtig bei der gleichzeitigen Verwendung von mehreren Clients: Eine Nachricht gilt als zugestellt, wenn sie an EINEM Client des Empfängers angekommen ist. Das kann bei wackeliger Internetverbindung dazu führen, dass Nachrichten scheinbar nicht zugestellt wurden - sie landen dann nur bei dem Gerät, dass gerade online ist. Zwar prüfen die meisten XMPP-Clients beim Wieder-Online-Gehen, ob in der Zwischenzeit Nachrichten eingetroffen sind, aber eben nicht alle. Ebenso ist undefiniert, was passiert, wenn ein Videoanruf gestartet werden soll, der Gesprächspartner aber mit mehreren Clients online ist, von denen nicht alle Videotelefonie unterstützen. Threema, Whatsapp usw. machen es sich einfach: Die verbieten schlicht die parallele Nutzung sowie Fremd-Clients.
Fortschritt
- 2021-01
- Neukonfiguration des bestehenden XMPP-Servers mit Korrektur der DNS-Einträge und Installation zusätzlicher benötigter Dienste
- 2021-02
- Implementierung abgeschlossen: Statt 52% jetzt 100% "XMPP Specifications compliance" beim Conversations.im-Compliance-Test, A-Scores beim IM Observatory Client- und Server-Test
- 2021-02
- Bingo-Domäne mit IMAP-Authentifizierung hinzugefügt, Conversejs aktualisiert
- 2021-08
- Serverkonfiguration auf Ansible umgestellt, dabei kleine Fehler behoben, neue Funktionen hinzugefügt, Conversejs aktualisiert.
- 2022-08
- Push-Services für Monal IM aktiviert
- 2022-09
- IRC-Transport
Files
Das Ansible-Playbook samt Inventory befinden sich hier: https://git.bingo-ev.de/infrastructure/xmpp