User:Rabbitseatcarrots/xmppguide

This page is for those new to XMPP and interested in learning some stuff. It also serves as a place for me to store some notes and stuff.

Recommended clients

This list is ordered by operating system and has clients that (in my opinion) are easy to use. In order for a client to be in this list, it must support:

• OMEMO E2E encryption in 1-to-1 chats.
• Multi User Chat, also known as group chats.
  • OMEMO-encrypted MUCs

Linux

• Gajim (used by me): A very feature complete XMPP client. Requires some setup. Recommended if you are going to be a MUC moderator or admin, as it is the only client implementing those features pretty much.
• Dino (used by me): Very good client, perfect for those new to XMPP

Windows

I didn't test any of these clients, as I don't have Windows

• Gajim: A very feature complete XMPP client. Requires some setup. Recommended if you are going to be a MUC moderator or admin, as it is the only client implementing those features pretty much.
• Dino, kinda: There's an unofficial Windows version, you can download it here. Never tested it, no guarantees.
• UWPX: Nice interface, supports MUC and OMEMO, should support encrypted MUCs oops, doesn't actually support OMEMO in group chats, but does in 1-to-1 (supports only decrypting OMEMO messages in group chats). Still, this app is being actively developed, should be added Soon^TM

IOS/MacOS

I didn't test any of these clients, as I don't have Apple devices

• Gajim: A very feature complete XMPP client. Requires some setup. Recommended if you are going to be a MUC moderator or admin, as it is the only client implementing those features pretty much.
• Monal: Looks good. Supports encrypted MUCs

Android

• Conversations (tested by me): You don't need to look any further, this client has it all. While you can build from source, I think this client is worth the 4 euros they ask for in Google Play (If you use a Googlified build of Android, otherwise build from source or check out Conversations on F-Droid)

Web browsers

To use these clients your server must support either XEP-0124 or RFC 7395. The majority of servers will support at least one of these. I recommend to download these clients and self-host them for security

• Converse.

Recommended servers

I recommend checking out whatever is on the A category in this list, pick one and check if they have a privacy policy you like.

Notes

How to create a private and encrypted MUC

By default, MUCs are public and anyone can join them. In order for clients to use OMEMO in these chats, the room must be configured as follows:

• Must be members-only! (invite-only, these invites can only be given by the group's admins, which is only the owner by default).
• Members' JIDs must be visible to participants!. Only admins can set this. In Dino, this option is called Permission to view JIDs. Set this to anyone. Don't worry, non participants cannot view the list of members if you set Make participants list public to No.
• Optional: Set Publicly Searchable to No. It's not like randos can join anyway.
• Optional: Enable message archival. Self explanatory, enable unless you are keeping your client open 24/7, which you aren't. Only admins can enable this.

Now you can set a name for the room, invite your friends and spam them the latest copypasta all at once!

Also note, if you add new members in the future, those members cannot view the message history, instead all those messages' text will be replaced with "This message was encrypted with OMEMO, but not for your device" or something similar, as those messages were sent before they were members, and thus the one sending those messages didn't know their OMEMO parameters.

Video and audio calls in XMPP

For more information on this feature, see XEP-0166 to learn about Jingle

Some clients offer the ability to perform video and audio calls (with some even offering group calls). Clients with this ability can be divided in 2 groups:

• Supporting XEP-0320 (DTLS-SRTP, aka encrypted calls): Conversations (Android), Dino (Linux and Windows, kinda) and any web client offering call support (these clients must use WebRTC for calls, which forces usage of DTLS-SRTP. This is theoretical, as I haven't seen any web client that offers calls support, but should a web client offering calls support exist, it should be able to call any other clients supporting this standard. See also A Study of WebRTC Security).
  • How this works: When the message to initiate a Jingle call is sent to an address, the client that's going to send it generates a cryptographic key pair, creates a self-signed certificate and sends the certificate's SHA-256 fingerprint. If the other client accepts the call, it generates another crypto key pair and follows the same steps as the call's initiator. This provides an authenticated and encrypted DTLS channel, which we can use to exchange the SRTP key through a DTLS extension, creating an end-to-end encrypted call. Simple, right?
• Not supporting XEP-0320: Gajim (Linux, Windows and Mac), and possibly the majority of clients offering this functionality.
  • How this works: These clients use unencrypted RTP to exchange audio and video data.

Calls through firewalls

If you try to call on mobile data networks without IPv6, or on devices connected to a network offering only a CGNATted IPv4 or who have a firewall without the required ports open, you will see that calls succeed regardless. How is this possible?

XMPP clients can establish calls either directly between themselves (by either binding to a port and listening to incoming connections, if the firewalls allow it, or by asking your home router to open ports through the UPnP protocol), or can ask for help from the server.

Good XMPP servers will offer TURN servers, which can be either operated by the server administrators of your XMPP server or a public service. Your client can ask the server to grant access to the TURN server to your client, which the server should grant, by giving you the TURN server's secret. Once your client has access, it can use this server as a proxy between you and the person you want to call. Using DTLS-SRTP is even more important in this scenario, to prevent the TURN server from recording the call.