Sergey Budaev

Messaging continues to be of rise. The new generation is more willing to send texts than to call. Communicating with an instant messenger has an unique advantage over the old good email: you can easily send replies over replies quickly, resulting in a dialogue. But there is a serious problem: many of the instant messengers are commercial products that work such that their "users" are in fact the exploitable resource having no control or choice.

Most corporations are fair providers of various products and services we can buy. But not these "Big Tech" that offer "free applications," including instant messengers. There is, obviously, nothing free on the Earth. Then, if you do not pay, then you are the product not the customer. The Big Tech corporations exploit the "end-users" to suck out private data, often for further resale. Nearly all of these messengers have centralised architecture and the user's account is linked to the telephone number, completely destroying privacy. The link to the telephone number is also very inconvenient because you cannot get several accounts easily, this requires obtaining several mobile subscriptions. It's just illogical, expensive and silly. Centralized architecture dictates that the communication is kept on the corporate servers so theoretically many employees can read messages by abuse.

Some of the products are advertised as end-to-end encrypted. But nearly all of them are closed source so there is no way to check how this is implemented and if and when the service owner can have access to private messages content. Moreover, we have evidence for the opposite. Many so called "end-to-end encrypted" messages are actually read by AI and human contractors. Even if communication is technically end-to-end encrypted, the company owns and fully controls the server, the client application and network traffic, so a man-in-the-middle attack by silently changing certificates is possible (e.g. in the context of lawful intercept, or unlawful abuse). Metadata (technical information information about all aspects of communication, including the addressees, their locations, IP addresses, telephone number etc.) is always accessible to the service. But metadata is often even more informative than the message content. How such metadata is used is typically unclear. The user has no authority here at all.

Nearly all of these messengering systems have closed proprietary protocol. This means that how you use the product is completely controlled by the owner company. The only way to use the product is with the official application. You cannot just choose for yourself which application program to use. This is cardinally different from the email, for example, where you can use the provider's web interface, its mobile app or any of the many available email applications such as Thunderbird or K-9 Mail. With such a third-party application you can easily consolidate several email accounts in one place and easily make use of the functionality the provider does not offer, such as end-to-end encryption. Another major problem is monopoly and lack of interoperability. The "users" (in reality, the exploited resource) are completely restricted to the owner's platform and are unable to communicate with the other (especially competing) platforms (e.g. Facebook to Snapchat) as a way to keep users within the silo. This is as if you were unable to call/send sms across different mobile operators. And this is silly. To break down monopoly, ensure fairer competition and interoperability across the services, the EU has developed the Digital Markets Act (DMA) regulation. This is a big step, but it does not solve many of the problems with centralization, privacy and regular security flaws.

Take back your freedom, privacy and security

So, why use the restricted, inconvenient, monopolistic, insecure and non-private platforms for the trivial task of sending instant messages? There are several ways to configure one's own privately controlled instant messaging system: XMPP and Matrix. XMPP is lightweight, easy to install, and more private and secure, yet covers all the typical instant communication purposes: text, file share and voice. Moreover, XMPP servers are by default federated: it is easy to send messages across the different servers like in the email. There are many different applications for all operating systems and platforms the user can choose. Update: XMPP can communicate with federated Matrix network because ejabberd now implements a Matrix gateway.

It is very easy to set up one's own XMPP server for a small group, company, the family or just an individual. You will need two things:

• Server that will be the central hub for the communication network running 24x7. This can be anything, from a Rasberry PI in a cupboard to a Virtual Private Server (VPS) somewhere in a data centre or just an old PC running in your basement. A small scale VPS useful for an XMPP server can be very cheap, up to a three Euro per month. There exist even cheaper options, such as EUR 6 per year. There are also dedicated search engines to help locate cheap VPS, e.g. LowendBox and ServerHunter. A typical operating system running on the server is Linux (very secure, highly configurable, free and open source).

• Domain name that needs to be used to connect to the XMPP server. Domain can be registered to the user (e.g. myname.no), which costs about 30 Euro yearly. But a sub-domain can be obtained for free using the https://freedns.afraid.org or similar "free DNS" services. In the later case you might have something like myownchat.mooo.com or myownchat.ptchat.net. Other free DNS options include Github pages, EU.org, is-a.dev, and DuckDNS. It is possible to run the XMPP server purely on IP address even without domain name, but it is much less convenient (e.g. then federation with other servers is lost).

Given you have got a server (VPS or dedicated machine) and the domain, configuring an XMPP server can be done on 1-2-3. There exist several Linux variants (distributives) with different management commands (usually for installing software). I assume Debian Linux is used below (the same commands also work for Ubuntu and other Debian-based Linux systems).

1. Install XMPP server software

Login. When you have got a server of any kind, you need tologin to it, typically with ssh:

ssh debian@1.2.3.4

here the user name on the server is debian and the server ip is 1.2.3.4. Typically, you may need to create the ssh key and upload it to the server to authenticate (refer the server documentation, e.g. this). I assume logging-in is not a problem.

Prepare server. First of all, update the software on the new server

sudo apt update -y && sudo apt-get upgrade -y

Install some useful monitoring and security-enhancing utilities

sudo apt install -y mc htop atop nload nmon tree zip pwgen fail2ban dnsutils iptables-persistent locate unattended-upgrades

Install certbot, a system that manages the TLS certificates for secure connection

sudo apt -y install certbot

Install the ejabberd server, which is is very reliable and light on resources

It is strongly recommended to install ejabberd package repository as explained here: https://repo.process-one.net/. Then ejabberd software will automatically update without need to download every new version from the site (use standard Debian command as sudo apt update && sudo apt upgrade).

sudo apt install ejabberd

Firewall. To allow incoming network access to this server by the XMPP clients and also third-party servers, the server needs to configure the firewall rules. This can be done differently in different installations. For example, some VPS may do this using a friendly web interface. The standard Linux firewall is done via iptables.

The XMPP system requires incoming acces via ports 5222, 5223, 5269, 5443, 5280, 3478. To determine the ports refer to the listen section of the XMPP configuration file below.

 sudo iptables -A INPUT -p tcp --dport 5222 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
 sudo iptables -A INPUT -p tcp --dport 5223 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
 sudo iptables -A INPUT -p tcp --dport 5269 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
 sudo iptables -A INPUT -p tcp --dport 5443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
 sudo iptables -A INPUT -p tcp --dport 5280 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

 # STUN is over udp
 sudo iptables -A INPUT -p udp --dport 3478 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

The port 7777 is used for a proxy for peer-to-peer (bytestream) file transfer. If peer-to-peer file sharing is intended for use, an additional rule should be set allowing incoming connections:

sudo iptables -A INPUT -p tcp --dport 7777 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

To see what firewall rules are in effect issue this:

 iptables -L --line-numbers

It makes sense to save the iptables rules so they are automatically get in effect after reboot

 iptables-save > /etc/iptables/rules.v4

2. Configure your XMPP server

Secure connection certificate. Get a free Let's Encrypt TLS certificate. I assume you have got a free domain myownchat.ptchat.net from https://freedns.afraid.org.

XMPP server will iideally need several subdomains (although may work with a single domain). In our case these are the following:

• main domain name: myownchat.ptchat.net
• conference: conference.myownchat.ptchat.net
• proxy: proxy.myownchat.ptchat.net
• pubsub: pubsub.myownchat.ptchat.net
• upload: upload.myownchat.ptchat.net

Note that ejabberd can manage (issue and update) TLS certificates on its own, but this needs some configuration as described in the acme configuration option: https://docs.ejabberd.im/admin/configuration/basic/#acme. An advantage of the standalone certificate management system (as here) is that it is slightly less tricky and can easily be used with a web server on the same machine. Why not also configure a web server for a small static web site here? Ejabberd is very lightweight and will happily coexist with many other servers running on the same machine. If a stand-alone XMPP server is required, check out the last section of this post on configuring acme. For now, do not configure TLS certificates certfiles: in the ejabberd.yml file, leave them as is with the default cerrtificates.

Before requesting certificate, you must be sure that incoming connections on the port 80 of the server are not blocked by firewall. If this is not so (port closed), use the following command:

sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT

Do not forget to save iptables rules with the iptables-save as above.

Now, it is time to request the certificate. Do this (minimal) command:

sudo certbot --standalone certonly -d myownchat.ptchat.net

or for all subdomains domains (strongly recommended!):

sudo certbot --standalone certonly -d myownchat.ptchat.net -d conference.myownchat.ptchat.net -d proxy.myownchat.ptchat.net -d pubsub.myownchat.ptchat.net -d upload.myownchat.ptchat.net

(note that the above is one line)

This command will ask a few questions and issue a TLS certificate.

The certificate files are located in /etc/letsencrypt/live/myownchat.ptchat.net/fullchain.pem directory.

For the sake of security, the certificate directories have by default no access to anyone except the admin (root) user. But this precludes the XMPP server ejabberd to access the certificate. This can be easily fixed with the following commands

First, add ejabberd to the root group

sudo adduser ejabberd root

Second, allow access to the certificate directories to the group

sudo chmod g+rx /etc/letsencrypt/live/myownchat.ptchat.net
sudo chmod g+rx /etc/letsencrypt/live
sudo chmod g+rx /etc/letsencrypt/

Configure ejabberd. Once the preparations are done, it is time to configure the ejabberd messaging server. Edit the configuration file (assuming the mcedit text editor is used)

• Check out example configuration here: ejabberd.yml

sudo mcedit /etc/ejabberd/ejabberd.yml

This is a long configuration file that may look scary. But in fact only a few changes are required to make the server running with the default options. But note that the indents are important, try to keep them as in the original file.

Any line starting with # is considered a comment, this can be easily used to disable specific options by "commenting them out."

First, set up the host name that is used for the server, it is the same as the domain:

 hosts:
  - myownchat.ptchat.net

Second, configure the location of the TLS certificates that are used by the server:

 certfiles:
  - "/etc/letsencrypt/live/myownchat.ptchat.net/fullchain.pem"
  - "/etc/letsencrypt/live/myownchat.ptchat.net/privkey.pem"

Configure how user passwords are stored on the server. While the default is plain text plain, it is more secure to use scram:

auth_password_format: scram

(Check out the doc:https://docs.ejabberd.im/admin/configuration/authentication/#supported-methods)

Configure the admin users who can manage the XMPP server:

 acl:
   admin:
      user:
       - "my_user_name@myownchat.ptchat.net"
       - "@localhost"

Then, add configuration for http-file-upload module that will allow file sharing (sending files):

 mod_http_upload:
    put_url: https://@HOST@:5443/upload
    custom_headers:
      "Access-Control-Allow-Origin": "https://@HOST@"
      "Access-Control-Allow-Methods": "GET,HEAD,PUT,OPTIONS"
      "Access-Control-Allow-Headers": "Content-Type"

It is convenient to keep the latest messages on the server, it is done with the "mam" module:

 mod_mam:
   assume_mam_usage: true
   default: always

Ejabberd supports several other communication protocols in addition to XMPP. For example, it also works with MQTT that is typically used for IoT devices. If this functionality is not used, just comment out the MQTT module to disable it.

 # mod_mqtt: {}

The STUN and TURN protocol is mainly used for voice calls and needs the actual IP address of the server (replace with your server IP addfress)

 -
   port: 3478
   ip: "::"
   transport: udp
   module: ejabberd_stun
   use_turn: true
   ## The server's public IPv4 address:
   turn_ipv4_address: "1.2.3.4"

An important issue is wether to allow anonymous registrations of new users. I strongly recommend not allowing this for security reasons. For a small private server, you will normally add users manually and set them initial passwords. Every user can then change password within the client program. So, you need to disable the mod_register by commenting it out:

 # mod_register:
 #   ## Only accept registration requests from the "trusted"
 #   ## network (see access_rules section above).
 #   ## Think twice before enabling registration from any
 #   ## address. See the Jabber SPAM Manifesto for details:
 #   ## https://github.com/ge0rg/jabber-spam-fighting-manifesto
 #   ip_access: trusted_network

Start server! And that's all minimal configuration. Now it's time to start the server:

sudo systemctl start ejabberd

If there are any errors and the server fails to start, Linux logs can be inspected with this command:

sudo journalctl -xe

or logs for only ejabberd:

sudo journalctl -xe --unit ejabberd

Additional stuff. The above is enough to make the XMPP server running for text. If voice is required, you need to configure the DNS as described here: https://www.process-one.net/blog/how-to-set-up-ejabberd-video-voice-calling/. DNS is normally configured using the control panel of the domain registrar.

The TLS certificate that is managed by certbot is updated each 90 days. This is an automatic process, but the ejabberd server must know when certificate is changed. This can be done using the deploy hook. Just create the hook file reloadxmpp.sh (the file name can be anything):

 sudo mcedit /etc/letsencrypt/renewal-hooks/deploy/reloadxmpp.sh

and add the following commands:

 #!/bin/sh
 ejabberdctl reload_config

This file must be executable, so issue this command:

 sudo chmod ugo+x /etc/letsencrypt/renewal-hooks/deploy/reloadxmpp.sh

The last note on the server is that it should be regularly updated for bug fixes and security updates. This is done automatically by installing unattended-upgrades above. Yet, it is a good practice to log in regularly over the ssh, check logs and update the system:

sudo apt update -y && sudo apt-get upgrade -y

3. Configure the XMPP users and client application

Register new users. First, you need to register the XMPP users. The quickest method is to use the command line on the server, the command ejabberdctl has advanced functions.

A secure random password can be generated withy pwgen, e.g. the following generates passwords with 18 symbols:

pwgen 18

It normally generates an array of possible passwords to choose from.

Now, to register the user myname, It is the admin user configured in the main configuration file /etc/ejabberd/ejabberd.yml above.

#                         user   domain               password
sudo ejabberdctl register myname myownchat.ptchat.net pee8chogh9Heel6hei

Other users can be configured similarly. Note that the full user name for XMPP has the same format se email: myname@myownchat.ptchat.net. This is due to the federated nature of both systems: you need to know both the user and the server with whom to communicate.

For this example let's register two additional users:

sudo ejabberdctl register john.dow myownchat.ptchat.net ohyeeLeefo9yief4gu
sudo ejabberdctl register anna.karenina myownchat.ptchat.net hejo7phiy2iFeW9She

Use! The final step is configure the client program on the user's device. The biggest difficulty at this step is the plenty of choice. For any major platform, one can choose any of the many available XMPP client programs. Some email programs, e.g. Thunderbird also support XMPP (although only a limited subset of features). Check out the https://xmpp.org. The configuration for the client is simple:

• Server: your server, in the example above it is myownchat.ptchat.net

• User name: your user name. In the example we used above, it can be myname

Note that the option to create new account must NOT be enabled as long as the account has already been created on the sever and the in-band registration (mod_register, see above) is disabled for security.

Some programs accept the full user name without specifying user and domain separately. Then the user is just myname@myownchat.ptchat.net. If you plan to use the peer-to-peer (bytestream) file transfer (but this is not mandatory), you should also find where the file transfer proxy is configured and set it with the proxy subdomain, for our example it should be proxy.myownchat.ptchat.net. And that is all for basic client configuration.

I recommend the Monocles XMPP application for devices running Android. Yaxim is the best option for minimalists, it is notoriously miniature (only a few megabytes) and works great even on the oldest and weakest devices. Gajim is perhaps the best XMPP client for Windows and Linux. Miranda NG is a powerful XMPP client program for Windows. There are also a few web-based clients: https://conversejs.org/ and https://web.xabber.com/ that you can try right away without installing anything. There is also a new cross-platform Fluux - check it out!

The final step is to fill the contact list (called roster) with the addresses of the people (or maybe devices, because XMPP can be easily configured for bots accepting commands). Just remember that the address is full name as in email: user@server.domain. One useful option is so called Shared roster groups: then you can configure a group of contacts without the need to add them manually.

Happy chatting!

Further

There are many advanced options and possibilities in ejabberd. Just check the documentation at the official web site: https://www.ejabberd.im/ and documentation https://docs.ejabberd.im/.

There are also a few useful tutorials that you may find useful e.g.

• https://www.process-one.net/blog/how-to-move-the-office-to-real-time-im-on-ejabberd/

• https://www.codedge.de/posts/modern-messaging-running-your-own-xmpp-server

• https://medium.com/geekculture/how-to-setup-an-xmpp-server-for-private-messaging-dcb1f4740fe

Secure connection for a stand-alone XMPP server

If you really like a stand-alone XMPP server that does not depend on certbot to get and update TLS certificates, ejabberd configuration can proceed slightly differently. Check outthis link:

• https://docs.ejabberd.im/admin/configuration/basic/#acme.

First, XMPP server will request the certificate and automatically update it itself as needed. But server is normally running with limited rights and has no access to the local port 80. No problem, port 80 can be forwarded using a few different tools. The simplest is sslh.

Port forwarding with sslh. Install sslh with

 sudo apt install sslh

Configure sslh to forward ports as needed, edit /etc/default/sslh file:

 DAEMON_OPTS="--user sslh --listen 0.0.0.0:80 --listen 0.0.0.0:443  --http 127.0.0.1:5280 --ssl 127.0.0.1:5443 --xmpp 127.0.0.1:5223 --pidfile /var/run/sslh/sslh.pid"

This makes sslh listen on both ports 80 (unenctypted http) and 443 (encrypted TLS) and forward the traffic depending on the protocol to the appropriate software. Note that this configuration also forwards traffic from port 443 to 5223 for more resilient direct TLS connection.

To enable the new configuration, restart sslh with

 sudo systemctl restart sslh

Configure acme in ejabberd. Now it's time to go the ejabberd configuration 'ejabberd.yml'

Fixed certificates are not needed any more then, comment them out:

#ca_file: /opt/ejabberd/conf/cacert.pem

#certfiles:
#  - /opt/ejabberd/conf/server.pem

Now check go to the listen part of the ejabberd configuration

listen:

And make this config:

listen:

# other congigs there

  # confugure for acme
  -
    port: 5280
    #ip: "::"
    module: ejabberd_http
    tls: false
    request_handlers:
      /.well-known/acme-challenge: ejabberd_acme

Now go somewhere above module configurations (modules:) and place the following

# ACME is enabled
acme:
    auto: true
    contact: "mailto:postmaster@your_email.fqdn"
    ## Staging environment
    ca_url: https://acme-staging-v02.api.letsencrypt.org/directory
    ## Production environment (the default):
    #ca_url: https://acme-v02.api.letsencrypt.org/directory

This uncomments temporary staging environment for checking and comments out the working config. Use it for initial tessting only.

Restart server for the configuration change to take effect

 sudo systemctl restart ejabberd

Now check that certificate request is working

ejabberdctl  request-certificate all

This will request certificates for all domains and subdomains

If there are no errors, comment out the staging environment and enable the production environment in the acme section:

# ACME is enabled
acme:
    auto: true
    contact: "mailto:postmaster@your_email.fqdn"
    ## Staging environment
    #ca_url: https://acme-staging-v02.api.letsencrypt.org/directory
    ## Production environment (the default):
    ca_url: https://acme-v02.api.letsencrypt.org/directory

Restart server for the configuration change to take effect

 sudo systemctl restart ejabberd

Now get the certificates!

 sudo ejabberdctl  request-certificate all

Check the certificates with

 sudo ejabberdctl list-certificates

If everythig went okay, ejabberd will care about TLS certificate update itself in the future. It's all for this section.

Make file upload more resilent Make use of port forwarding by sslh 443 to 5443 for XMPP file upload. This will help share files in restricted environments that do not allow access to ports except 443.

For this, go to the mod_http_upload configuration and make a copy of the line with the put_url parameter as before and comment out the line with :5443

  mod_http_upload:
    #put_url: https://@HOST@:5443/upload
    put_url: https://@HOST@/upload
    thumbnail: false
    access: local
    custom_headers:
      "Access-Control-Allow-Origin": "*"
      "Access-Control-Allow-Methods": "GET, POST, PUT, OPTIONS, DELETE"
      "Access-Control-Allow-Headers": "Content-Type, Origin, X-Requested-With"

Restart server to make this change to take effect

 sudo systemctl restart ejabberd

Now try to connect and send file, if there are problems that are hard to fix, you can revert port 5443 use.

Simple web server

The stand-alone configuration of ejabberd allows slso to use it as a simple stand-alone web server. Then, one needs to add a reference to the mod_http_fileserver module in the appropriate 'listen' section request_handlers. Best use port 5443 that will forward from sslh 443. Then common URL can be used to access the content.

Here is an example, check out the last line. It shows that the URL starting with just / will be served by the mod_http_fileserver module, efficiently serving https://myownchat.ptchat.net:5443/.

  -
    port: 5443
    ip: "::"
    module: ejabberd_http
    tls: true
    request_handlers:
      "/admin": ejabberd_web_admin
      #"/api": mod_http_api
      "/bosh": mod_bosh
      #"/captcha": ejabberd_captcha
      "/upload": mod_http_upload
      "/ws": ejabberd_http_ws
      #"/oauth": ejabberd_oauth
      "/conversejs": mod_conversejs
      # Web server configuration
      /: mod_http_fileserver

Additionally, you also need to configure the mod_http_fileserver module. Below, the root will refer to the directory /opt/www (docroot parameter), allowing use the browser address https://myownchat.ptchat.net. Also, the index files are defined by directory_indices parameter: this is the name of the file that is returned and shown by default. Such a configuration is an easy way to make a launch page for the server with a hyperlink to the conversejs https://myownchat.ptchat.net/conversejs. Just place an appropriately written index.html into /opt/www.

  mod_http_fileserver:
    docroot:
      /: /opt/www
      directory_indices: ["index.html", "index.html"]

Check out documentation here: https://docs.ejabberd.im/admin/configuration/modules/#mod_http_fileserver

Example configuration file

Here you can download an example configuration file for a stand-alone XMPP server that controls the acme-based update of TLS itself. Adapt it to your needs.

• Download example configuration: ejabberd.yml (or GitHub: https://github.com/sbudaev/xmpp-1-2-3)

Note that this configuration also enables conversejs web interface and http file server for the landing page.

Note that to make OMEMO end-to end encryption functional in the ConverseJS installation, you need to download the latest release from https://github.com/conversejs/converse.js/releases and place it somewhere on the server (the configuration uses path defined in conversejs_resources:, here"/opt/lib/conversejs/package/dist"). then make subdirectory /opt/lib/conversejs/package/dist/plugins and place all libsignal-protocol "js" files to plugins. Check out documentation here: https://docs.ejabberd.im/admin/configuration/modules/#mod_conversejs

###
###           ejabberd configuration file
###
### The parameters used in this configuration file are explained at
###
###       https://docs.ejabberd.im/admin/configuration
###
### The configuration file is written in YAML.
### *******************************************************
### *******           !!! WARNING !!!               *******
### *******     YAML IS INDENTATION SENSITIVE       *******
### ******* MAKE SURE YOU INDENT SECTIONS CORRECTLY *******
### *******************************************************
### Refer to http://en.wikipedia.org/wiki/YAML for the brief description.
###
### $Id: ejabberd.yml 1790 2026-03-14 15:30:37Z budaev $
###

hosts:
  - "myownchat.ptchat.net"

loglevel: info
log_rotate_size: 5242880
log_rotate_count: 4

# Default database type for a module lacking db_type option or if 
# auth_method option is not set.
default_db: mnesia

# The option defines in what format the users passwords are stored, plain text
# or in SCRAM format:
# scram: The password is not stored, only some information required to verify
# the hash provided by the client. It is impossible to obtain the original
# plain password from the stored information; for this reason, when this value
# is configured it cannot be changed to plain anymore. This format allows
# clients to authenticate using: SASL PLAIN and SASL
# SCRAM-SHA-1/256/512(-PLUS). The SCRAM variant depends on the auth_scram_hash
# option.
auth_password_format: scram

#ca_file: /opt/ejabberd/conf/cacert.pem

#certfiles:
#  - /opt/ejabberd/conf/server.pem

listen:
  -
    port: 5222
    ip: "::"
    module: ejabberd_c2s
    max_stanza_size: 262144
    shaper: c2s_shaper
    access: c2s
    starttls_required: true

  # Direct-TLS for C2S (XEP-0368). Good practice is to forward  traffic from
  # port 443 to 5223, possibly multiplexing with HTTP using e.g. sslh
  # [https://wiki.xmpp.org/web/Tech_pages/XEP-0368], so modern clients can
  # bypass restrictive firewalls (in airports, hotels, etc.).
  -
    port: 5223
    ip: "::"
    module: ejabberd_c2s
    tls: true
    max_stanza_size: 65536
    shaper: c2s_shaper
    access: c2s
  -
    port: 5269
    ip: "::"
    module: ejabberd_s2s_in
    max_stanza_size: 524288
  -
    ## s2s with tls enforced
    port: 5270
    ip: "::"
    module: ejabberd_s2s_in
    max_stanza_size: 524288
    shaper: s2s_shaper
    tls: true
  -
    port: 5443
    ip: "::"
    module: ejabberd_http
    tls: true
    request_handlers:
      "/admin": ejabberd_web_admin
      #"/api": mod_http_api
      "/bosh": mod_bosh
      #"/captcha": ejabberd_captcha
      "/upload": mod_http_upload
      "/ws": ejabberd_http_ws
      #"/oauth": ejabberd_oauth
      /conversejs: mod_conversejs
      /: mod_http_fileserver

  # confugure for acme
  -
    port: 5280
    #ip: "::"
    module: ejabberd_http
    tls: false
    request_handlers:
      /.well-known/acme-challenge: ejabberd_acme

  # needed for audio/video, see
  # https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-server-admins
  -
    port: 3478
    ip: "::"
    transport: udp
    module: ejabberd_stun
    use_turn: true
    ## The server's public IPv4 address:
    turn_ipv4_address: "111.222.333.444"
    ## The server's public IPv6 address:
    # turn_ipv6_address: "2001:db8::3"

#  -
#    port: 1883
#    ip: "::"
#    module: mod_mqtt
#    backlog: 1000

## Disabling digest-md5 SASL authentication. digest-md5 requires plain-text
### password storage (see auth_password_format option).
disable_sasl_mechanisms:
  - "digest-md5"
  - "X-OAUTH2"

s2s_use_starttls: required

acl:
  local:
    user_regexp: ""
  loopback:
    ip:
      - 127.0.0.0/8
      - ::1/128
      - ::FFFF:127.0.0.1/128
  admin:
    user:
       - "my_user_name@myownchat.ptchat.net"
       - "@localhost"

access_rules:
  local:
    allow: local
  c2s:
    deny: blocked
    allow: all
  ## Only admins can send announcement messages:
  announce:
    allow: admin
  ## Only admins can use the configuration interface:
  configure:
    allow: admin
  ## Only accounts of the local ejabberd server can create rooms:
  muc_create:
    allow: local
  ## Only accounts on the local ejabberd server can create Pubsub nodes:
  pubsub_createnode:
    allow: local
  ## Only allow to register from localhost
  trusted_network:
    allow: loopback

api_permissions:
  "webadmin":
    from:
      - ejabberd_web_admin
    who:
      access:
        allow:
          acl: admin
    what:
      - "*"    
  "console commands":
    from:
      - ejabberd_ctl
    who: all
    what: "*"
  "admin access":
    who:
      access:
        allow:
          acl: loopback
          acl: admin
      oauth:
        scope: "ejabberd:admin"
        access:
          allow:
            acl: loopback
            acl: admin
    what:
      - "*"
      - "!stop"
      - "!start"
  "public commands":
    who:
      ip: 127.0.0.1/8
    what:
      - status
      - connected_users_number

shaper:
  normal: 1000
  fast: 50000

shaper_rules:
  max_user_sessions: 10
  max_user_offline_messages:
    5000: admin
    100: all
  c2s_shaper:
    none: admin
    normal: all
  s2s_shaper: fast

max_fsm_queue: 10000

# ACME is ensabled
acme:
    auto: true
    contact: "mailto:postmaster@your_email.fqdn"      
    ## Staging environment
    ca_url: https://acme-staging-v02.api.letsencrypt.org/directory
    ## Production environment (the default):
    #ca_url: https://acme-v02.api.letsencrypt.org/directory

modules:
  mod_adhoc: {}
  mod_admin_extra: {}
  mod_announce:
    access: announce
  mod_avatar: {}
  mod_blocking: {}
  mod_bosh: {}
  mod_conversejs:
    websocket_url: auto
    #conversejs_css: https://cdn.conversejs.org/12.0.0/dist/converse.min.css
    #conversejs_css: https://cdn.conversejs.org/12.0.0/dist/converse.css
    #conversejs_script: https://cdn.conversejs.org/12.0.0/dist/converse.min.js
    #conversejs_script: https://cdn.conversejs.org/12.0.0/dist/converse.js
    conversejs_resources: "/opt/lib/conversejs/package/dist"
    conversejs_plugins: ["libsignal-protocol.min.js"]
    #conversejs_plugins: ["libsignal-protocol.js"]
    # File path is: /opt/lib/conversejs/package/dist/plugins/libsignal-protocol.min.js
    conversejs_options:
      default_domain: "myownchat.ptchat.net"
      embed_3rd_party_media_players: true
      enable_smacks: true
      auto_away: 30
      auto_reconnect: true
      synchronize_availability: false
      message_carbons: true
      omemo_default: true
      show_images_inline: true
      clear_cache_on_logout: false
      i18n: "ru"
      locked_domain: "@HOST@"
      message_archiving: always
      auto_list_rooms: true
      auto_join_on_invite: true
      theme: dracula
  mod_caps: {}
  mod_carboncopy: {}
  mod_client_state: {}
  mod_configure: {}
  mod_disco: {}
  mod_fail2ban: {}
  mod_http_api: {}
  mod_http_upload:
    #put_url: https://@HOST@:5443/upload
    put_url: https://@HOST@/upload
    docroot: "/var/ejabberd/upload"
    thumbnail: false
    access: local
    custom_headers:
      "Access-Control-Allow-Origin": "*"
      "Access-Control-Allow-Methods": "GET, POST, PUT, OPTIONS, DELETE"
      "Access-Control-Allow-Headers": "Content-Type, Origin, X-Requested-With"
  # Configure fileserver serving lounching page
  mod_http_fileserver:
    docroot:
      /: /opt/www
    directory_indices: ["index.html", "index.html"]
    accesslog: /var/log/ejabberd/access.log
  mod_last: {}
  mod_mam:
    ## Mnesia is limited to 2GB, better to use an SQL backend
    ## For small servers SQLite is a good fit and is very easy
    ## to configure. Uncomment this when you have SQL configured:
    db_type: mnesia
    assume_mam_usage: true
    default: always
  # mod_mqtt: {}
  mod_muc:
    access:
      - allow
    access_admin:
      - allow: admin
    access_create: muc_create
    access_persistent: muc_create
    access_mam:
      - allow
    default_room_options:
      allow_subscription: true  # enable MucSub
      mam: true
  mod_muc_admin: {}
  mod_muc_log: {}
  mod_muc_occupantid: {}
  mod_offline:
    access_max_user_messages: max_user_offline_messages
  mod_ping: {}
  mod_privacy: {}
  mod_private: {}
  mod_proxy65:
    access: local
    max_connections: 50
  mod_pubsub:
    access_createnode: pubsub_createnode
    plugins:
      - flat
      - pep
    force_node_config:
      #"eu.siacs.conversations.axolotl.*":
      #  access_model: open
      ## Avoid buggy clients to make their bookmarks public
      storage:bookmarks:
        access_model: whitelist
  mod_push: {}
  mod_push_keepalive: {}
  # mod_register:
  #   ## Only accept registration requests from the "trusted"
  #   ## network (see access_rules section above).
  #   ## Think twice before enabling registration from any
  #   ## address. See the Jabber SPAM Manifesto for details:
  #   ## https://github.com/ge0rg/jabber-spam-fighting-manifesto
  #   ip_access: trusted_network
  mod_roster:
    versioning: true
  # mod_s2s_dialback: {}
  # mod_s2s_bidi: {}
  mod_shared_roster: {}
  mod_stream_mgmt:
    resend_on_timeout: if_offline
  # mod_stun_disco -- needed for audio/video, see
  # https://gist.github.com/iNPUTmice/a28c438d9bbf3f4a3d4c663ffaa224d9#notes-for-server-admins
  # and also https://www.process-one.net/blog/how-to-set-up-ejabberd-video-voice-calling/
  mod_stun_disco: {}
  mod_vcard: {}
  mod_vcard_xupdate: {}
  mod_version:
    show_os: false

### Local Variables:
### mode: yaml
### End:
#