mod_adhoc

This module implements XEP-0050: Ad-Hoc Commands. It’s an auxiliary module and is only needed by some of the other modules.

Available options:

mod_admin_extra

This module provides additional administrative commands.

Details for some commands:

The module has no options.

Examples:

acl:
  adminextraresource:
    - resource: "modadminextraf8x,31ad"
access_rules:
  vcard_set:
    - allow: adminextraresource
modules:
  mod_admin_extra: {}
  mod_vcard:
    access_set: vcard_set

[{<<"bob">>, <<"example.org">>, <<"workers">>, <<"Bob">>},
{<<"mart">>, <<"example.org">>, <<"workers">>, <<"Mart">>},
{<<"Rich">>, <<"example.org">>, <<"bosses">>, <<"Rich">>}].

ejabberdctl vhost example.org ban_account boby "Spammed rooms"

ejabberdctl srg_create g1 example.org "'Group number 1'" this_is_g1 g1

mod_admin_update_sql

This module can be used to update existing SQL database from the default to the new schema. Check the section database.md#default-and-new-schemas|Default and New Schemas for details. Please note that only MS SQL, MySQL, and PostgreSQL are supported. When the module is loaded use update_sql API.

The module has no options.

mod_announce

This module enables configured users to broadcast announcements and to set the message of the day (MOTD). Configured users can perform these actions with an XMPP client either using Ad-hoc Commands or sending messages to specific JIDs.

Note that this module can be resource intensive on large deployments as it may broadcast a lot of messages. This module should be disabled for instances of ejabberd with hundreds of thousands users.

The Ad-hoc Commands are listed in the Server Discovery. For this feature to work, mod_adhoc must be enabled.

The specific JIDs where messages can be sent are listed below. The first JID in each entry will apply only to the specified virtual host example.org, while the JID between brackets will apply to all virtual hosts in ejabberd:

Available options:

mod_avatar

The purpose of the module is to cope with legacy and modern XMPP clients posting avatars. The process is described in XEP-0398: User Avatar to vCard-Based Avatars Conversion.

Also, the module supports conversion between avatar image formats on the fly.

The module depends on mod_vcard, mod_vcard_xupdate and mod_pubsub.

Available options:

convert:
  webp: jpg
  default: png

mod_block_strangers

This module blocks and logs any messages coming from an unknown entity. If a writing entity is not in your roster, you can let this module drop and/or log the message. By default you’ll just not receive message from that entity. Enable this module if you want to drop SPAM messages.

Available options:

mod_blocking

The module implements XEP-0191: Blocking Command.

This module depends on mod_privacy where all the configuration is performed.

The module has no options.

mod_bosh

This module implements XMPP over BOSH as defined in XEP-0124 and XEP-0206. BOSH stands for Bidirectional-streams Over Synchronous HTTP. It makes it possible to simulate long lived connections required by XMPP over the HTTP protocol. In practice, this module makes it possible to use XMPP in a browser without WebSocket support and more generally to have a way to use XMPP while having to get through an HTTP proxy.

Available options:

Example:

listen:
  -
    port: 5222
    module: ejabberd_c2s
  -
    port: 5443
    module: ejabberd_http
    request_handlers:
      /bosh: mod_bosh
modules:
  mod_bosh: {}

mod_caps

This module implements XEP-0115: Entity Capabilities. The main purpose of the module is to provide PEP functionality (see mod_pubsub).

Available options:

mod_carboncopy

The module implements XEP-0280: Message Carbons. The module broadcasts messages on all connected user resources (devices).

The module has no options.

mod_client_state

This module allows for queueing certain types of stanzas when a client indicates that the user is not actively using the client right now (see XEP-0352: Client State Indication). This can save bandwidth and resources.

A stanza is dropped from the queue if it’s effectively obsoleted by a new one (e.g., a new presence stanza would replace an old one from the same client). The queue is flushed if a stanza arrives that won’t be queued, or if the queue size reaches a certain limit (currently 100 stanzas), or if the client becomes active again.

Available options:

mod_configure

The module provides server configuration functionality via XEP-0050: Ad-Hoc Commands. Implements many commands as defined in XEP-0133: Service Administration. This module requires mod_adhoc to be loaded.

The module has no options.

mod_conversejs

Note about this option: added in 21.12 and improved in 22.05.

This module serves a simple page for the Converse XMPP web browser client.

To use this module, in addition to adding it to the modules section, you must also enable it in listen → ejabberd_http → listen-options.md#request_handlers|request_handlers.

Make sure either mod_bosh or ejabberd_http_ws listen-options.md#request_handlers|request_handlers are enabled.

When conversejs_css and conversejs_script are auto, by default they point to the public Converse client.

Available options:

Examples:

listen:
  -
    port: 5280
    module: ejabberd_http
    request_handlers:
      /bosh: mod_bosh
      /websocket: ejabberd_http_ws
      /conversejs: mod_conversejs
modules:
  mod_bosh: {}
  mod_conversejs:
    websocket_url: "ws://@HOST@:5280/websocket"

listen:
  -
    port: 443
    module: ejabberd_http
    tls: true
    request_handlers:
      /websocket: ejabberd_http_ws
      /conversejs: mod_conversejs
modules:
  mod_conversejs:
    conversejs_resources: "/home/ejabberd/conversejs-9.0.0/package/dist"

modules:
  mod_conversejs:
    websocket_url: auto
    conversejs_options:
      auto_away: 30
      clear_cache_on_logout: true
      i18n: "pt"
      locked_domain: "@HOST@"
      message_archiving: always
      theme: dracula

mod_delegation

This module is an implementation of XEP-0355: Namespace Delegation. Only admin mode has been implemented by now. Namespace delegation allows external services to handle IQ using specific namespace. This may be applied for external PEP service.

Available options:

Examples:

access_rules:
  external_pubsub:
    allow: external_component
  external_mam:
    allow: external_component
acl:
  external_component:
    server: sat-pubsub.example.org
modules:
  mod_delegation:
    namespaces:
      urn:xmpp:mam:1:
        access: external_mam
      http://jabber.org/protocol/pubsub:
        access: external_pubsub

mod_disco

This module adds support for XEP-0030: Service Discovery. With this module enabled, services on your server can be discovered by XMPP clients.

Available options:

server_info:
  -
    modules: all
    name: abuse-addresses
    urls: ["mailto:abuse@shakespeare.lit"]
  -
    modules: [mod_muc]
    name: "Web chatroom logs"
    urls: ["http://www.example.org/muc-logs"]
  -
    modules: [mod_disco]
    name: feedback-addresses
    urls:
      - http://shakespeare.lit/feedback.php
      - mailto:feedback@shakespeare.lit
      - xmpp:feedback@shakespeare.lit
  -
    modules:
      - mod_disco
      - mod_vcard
    name: admin-addresses
    urls:
      - mailto:xmpp@shakespeare.lit
      - xmpp:admins@shakespeare.lit

mod_fail2ban

The module bans IPs that show the malicious signs. Currently only C2S authentication failures are detected.

Unlike the standalone program, mod_fail2ban clears the record of authentication failures after some time since the first failure or on a successful authentication. It also does not simply block network traffic, but provides the client with a descriptive error message.

Available options:

mod_host_meta

Note about this option: added in 22.05.

This module serves small host-meta files as described in XEP-0156: Discovering Alternative XMPP Connection Methods.

To use this module, in addition to adding it to the modules section, you must also enable it in listen → ejabberd_http → listen-options.md#request_handlers|request_handlers.

Notice it only works if ejabberd_http has tls enabled.

Available options:

Example:

listen:
  -
    port: 443
    module: ejabberd_http
    tls: true
    request_handlers:
      /bosh: mod_bosh
      /ws: ejabberd_http_ws
      /.well-known/host-meta: mod_host_meta
      /.well-known/host-meta.json: mod_host_meta
modules:
  mod_bosh: {}
  mod_host_meta:
    bosh_service_url: "https://@HOST@:5443/bosh"
    websocket_url: "wss://@HOST@:5443/ws"

mod_http_api

This module provides a ReST interface to call ../../developer/ejabberd-api/index.md|ejabberd API commands using JSON data.

To use this module, in addition to adding it to the modules section, you must also enable it in listen → ejabberd_http → listen-options.md#request_handlers|request_handlers.

To use a specific API version N, when defining the URL path in the request_handlers, add a vN. For example: /api/v2: mod_http_api

To run a command, send a POST request to the corresponding URL: http://localhost:5280/api/<command_name>

The module has no options.

Example:

listen:
  -
    port: 5280
    module: ejabberd_http
    request_handlers:
      /api: mod_http_api
modules:
  mod_http_api: {}

mod_http_fileserver

This simple module serves files from the local disk over HTTP.

Available options:

content_types:
  .css: text/css
  .gif: image/gif
  .html: text/html
  .jar: application/java-archive
  .jpeg: image/jpeg
  .jpg: image/jpeg
  .js: text/javascript
  .png: image/png
  .svg: image/svg+xml
  .txt: text/plain
  .xml: application/xml
  .xpi: application/x-xpinstall
  .xul: application/vnd.mozilla.xul+xml

Examples:

listen:
  -
    port: 5280
    module: ejabberd_http
    request_handlers:
      /pub/content: mod_http_fileserver
modules:
  mod_http_fileserver:
    docroot: /var/www
    accesslog: /var/log/ejabberd/access.log
    directory_indices:
      - index.html
      - main.htm
    custom_headers:
      X-Powered-By: Erlang/OTP
      X-Fry: "It's a widely-believed fact!"
    content_types:
      .ogg: audio/ogg
      .png: image/png
    default_content_type: text/html

mod_http_upload

This module allows for requesting permissions to upload a file via HTTP as described in XEP-0363: HTTP File Upload. If the request is accepted, the client receives a URL for uploading the file and another URL from which that file can later be downloaded.

In order to use this module, it must be enabled in listen → ejabberd_http → listen-options.md#request_handlers|request_handlers.

Available options:

# This XML representation of vCard:
#   <vCard xmlns='vcard-temp'>
#     <FN>Conferences</FN>
#     <ADR>
#       <WORK/>
#       <STREET>Elm Street</STREET>
#     </ADR>
#   </vCard>
#
# is translated to:
vcard:
  fn: Conferences
  adr:
    -
      work: true
      street: Elm Street

Example:

listen:
  -
    port: 5443
    module: ejabberd_http
    tls: true
    request_handlers:
      /upload: mod_http_upload
modules:
  mod_http_upload:
    docroot: /ejabberd/upload
    put_url: "https://@HOST@:5443/upload"

mod_http_upload_quota

This module adds quota support for mod_http_upload.

This module depends on mod_http_upload.

Available options:

Examples:

shaper_rules:
  soft_upload_quota:
    1000: all # MiB
  hard_upload_quota:
    1100: all # MiB
modules:
  mod_http_upload: {}
  mod_http_upload_quota:
    max_days: 100

mod_jidprep

This module allows XMPP clients to ask the server to normalize a JID as per the rules specified in RFC 6122: XMPP Address Format. This might be useful for clients in certain constrained environments, or for testing purposes.

Available options:

mod_last

This module adds support for XEP-0012: Last Activity. It can be used to discover when a disconnected user last accessed the server, to know when a connected user was last active on the server, or to query the uptime of the ejabberd server.

Available options:

mod_legacy_auth

The module implements XEP-0078: Non-SASL Authentication.

The module has no options.

mod_mam

This module implements XEP-0313: Message Archive Management and XEP-0441: Message Archive Management Preferences. Compatible XMPP clients can use it to store their chat history on the server.

Available options:

mod_matrix_gw

Note about this option: added in 24.02.

Matrix gateway.

Available options:

Example:

listen:
  -
    port: 8448
    module: ejabberd_http
    tls: true
    request_handlers:
      "/_matrix": mod_matrix_gw
modules:
  mod_matrix_gw:
    key_name: "key1"
    key: "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"
    matrix_id_as_jid: true

mod_metrics

This module sends events to external backend (by now only grapherl is supported). Supported events are:

When enabled, every call to these hooks triggers a counter event to be sent to the external backend.

Available options:

mod_mix

Note about this option: added in 16.03 and improved in 19.02.

This module is an experimental implementation of XEP-0369: Mediated Information eXchange (MIX). It’s asserted that the MIX protocol is going to replace the MUC protocol in the future (see mod_muc).

To learn more about how to use that feature, you can refer to our tutorial: ../../tutorials/mix-010.md|Getting started with MIX

The module depends on mod_mam.

Available options:

mod_mix_pam

This module implements XEP-0405: Mediated Information eXchange (MIX): Participant Server Requirements. The module is needed if MIX compatible clients on your server are going to join MIX channels (either on your server or on any remote servers).

Available options:

mod_mqtt

This module adds ../guide/mqtt/index.md|support for the MQTT protocol version 3.1.1 and 5.0. Remember to configure mod_mqtt in modules and listen sections.

Available options:

mod_mqtt_bridge

This module adds ability to synchronize local MQTT topics with data on remote servers It can update topics on remote servers when local user updates local topic, or can subscribe for changes on remote server, and update local copy when remote data is updated. It is available since ejabberd 23.01.

Available options:

Example:

modules:
  mod_mqtt_bridge:
    servers:
      "mqtt://server.com":
        publish:
          "localA": "remoteA" # local changes to 'localA' will be replicated on remote server as 'remoteA'
          "topicB": "topicB"
        subscribe:
          "remoteB": "localB" # changes to 'remoteB' on remote server will be stored as 'localB' on local server
        authentication:
          certfile: "/etc/ejabberd/mqtt_server.pem"
    replication_user: "mqtt@xmpp.server.com"

mod_muc

This module provides support for XEP-0045: Multi-User Chat. Users can discover existing rooms, join or create them. Occupants of a room can chat in public or have private chats.

The MUC service allows any Jabber ID to register a nickname, so nobody else can use that nickname in any room in the MUC service. To register a nickname, open the Service Discovery in your XMPP client and register in the MUC service.

It is also possible to register a nickname in a room, so nobody else can use that nickname in that room. If a nick is registered in the MUC service, that nick cannot be registered in any room, and vice versa: a nick that is registered in a room cannot be registered at the MUC service.

This module supports clustering and load balancing. One module can be started per cluster node. Rooms are distributed at creation time on all available MUC module instances. The multi-user chat module is clustered but the rooms themselves are not clustered nor fault-tolerant: if the node managing a set of rooms goes down, the rooms disappear and they will be recreated on an available node on first connection attempt.

Available options:

presence_broadcast:
  - moderator
  - participant
  - visitor

# This XML representation of vCard:
#   <vCard xmlns='vcard-temp'>
#     <FN>Conferences</FN>
#     <ADR>
#       <WORK/>
#       <STREET>Elm Street</STREET>
#     </ADR>
#   </vCard>
#
# is translated to:
vcard:
  fn: Conferences
  adr:
    -
      work: true
      street: Elm Street

mod_muc_admin

This module provides commands to administer local MUC services and their MUC rooms. It also provides simple WebAdmin pages to view the existing rooms.

This module depends on mod_muc.

Available options:

mod_muc_log

This module enables optional logging of Multi-User Chat (MUC) public conversations to HTML. Once you enable this module, users can join a room using a MUC capable XMPP client, and if they have enough privileges, they can request the configuration form in which they can set the option to enable room logging.

Features:

The module depends on mod_muc.

Available options:

file_permissions:
  mode: 644
  group: 33

top_link:
  /: Home

mod_muc_occupantid

Note about this option: added in 23.10.

This module implements XEP-0421: Anonymous unique occupant identifiers for MUCs.

When the module is enabled, the feature is enabled in all semi-anonymous rooms.

The module has no options.

mod_muc_rtbl

Note about this option: added in 23.04.

This module implement Real-time blocklists for MUC rooms.

It works by observing remote pubsub node conforming with specification described in https://xmppbl.org/.

Available options:

mod_multicast

This module implements a service for XEP-0033: Extended Stanza Addressing.

Available options:

# Default values:
local:
  message: 100
  presence: 100
remote:
  message: 20
  presence: 20

Example:

# Only admins can send packets to multicast service
access_rules:
  multicast:
    - allow: admin
# If you want to allow all your users:
access_rules:
  multicast:
    - allow
# This allows both admins and remote users to send packets,
# but does not allow local users
acl:
  allservers:
    server_glob: "*"
access_rules:
  multicast:
    - allow: admin
    - deny: local
    - allow: allservers
modules:
  mod_multicast:
     host: multicast.example.org
     access: multicast
     limits:
       local:
         message: 40
         presence: infinite
       remote:
         message: 150

mod_offline

This module implements XEP-0160: Best Practices for Handling Offline Messages and XEP-0013: Flexible Offline Message Retrieval. This means that all messages sent to an offline user will be stored on the server until that user comes online again. Thus it is very similar to how email works. A user is considered offline if no session presence priority > 0 are currently open.

Available options:

Examples:

acl:
  admin:
    user:
      - admin1@localhost
      - admin2@example.org
  poweruser:
    user:
      - bob@example.org
      - jane@example.org
shaper_rules:
  max_user_offline_messages:
    - 5000: poweruser
    - 2000: admin
    - 100
modules:
  ...
  mod_offline:
    access_max_user_messages: max_user_offline_messages
  ...

mod_ping

This module implements support for XEP-0199: XMPP Ping and periodic keepalives. When this module is enabled ejabberd responds correctly to ping requests, as defined by the protocol.

Available options:

Example:

modules:
  mod_ping:
    send_pings: true
    ping_interval: 4 min
    timeout_action: kill

mod_pres_counter

This module detects flood/spam in presence subscriptions traffic. If a user sends or receives more of those stanzas in a given time interval, the exceeding stanzas are silently dropped, and a warning is logged.

Available options:

Example:

modules:
  mod_pres_counter:
    count: 5
    interval: 30 secs

mod_privacy

This module implements XEP-0016: Privacy Lists.

Available options:

mod_private

This module adds support for XEP-0049: Private XML Storage.

Using this method, XMPP entities can store private data on the server, retrieve it whenever necessary and share it between multiple connected clients of the same user. The data stored might be anything, as long as it is a valid XML. One typical usage is storing a bookmark of all user’s conferences (XEP-0048: Bookmarks).

It also implements the bookmark conversion described in XEP-0402: PEP Native Bookmarks, see the command bookmarks_to_pep API.

Available options:

mod_privilege

Note about this option: improved in 24.10.

This module is an implementation of XEP-0356: Privileged Entity. This extension allows components to have privileged access to other entity data (send messages on behalf of the server or on behalf of a user, get/set user roster, access presence information, etc.). This may be used to write powerful external components, for example implementing an external PEP or MAM service.

By default a component does not have any privileged access. It is worth noting that the permissions grant access to the component to a specific data type for all users of the virtual host on which mod_privilege is loaded.

Make sure you have a listener configured to connect your component. Check the section about listening ports for more information.

Available options:

Example:

modules:
  mod_privilege:
    iq:
      http://jabber.org/protocol/pubsub:
        get: all
    roster:
      get: all
    presence:
      managed_entity: all
    message:
      outgoing: all

mod_proxy65

This module implements XEP-0065: SOCKS5 Bytestreams. It allows ejabberd to act as a file transfer proxy between two XMPP clients.

Available options:

Example:

acl:
  admin:
    user: admin@example.org
  proxy_users:
    server: example.org
access_rules:
  proxy65_access:
    allow: proxy_users
shaper_rules:
  proxy65_shaper:
    none: admin
  proxyrate: proxy_users
shaper:
  proxyrate: 10240
modules:
  mod_proxy65:
    host: proxy1.example.org
    name: "File Transfer Proxy"
    ip: 200.150.100.1
    port: 7778
    max_connections: 5
    access: proxy65_access
    shaper: proxy65_shaper
    recbuf: 10240
    sndbuf: 10240

mod_pubsub

This module offers a service for XEP-0060: Publish-Subscribe. The functionality in mod_pubsub can be extended using plugins. The plugin that implements PEP (XEP-0163: Personal Eventing via Pubsub) is enabled in the default ejabberd configuration file, and it requires mod_caps.

Available options:

force_node_config:
  ## Avoid buggy clients to make their bookmarks public
  storage:bookmarks:
    access_model: whitelist

modules:
  ...
  mod_pubsub:
    pep_mapping:
      http://jabber.org/protocol/tune: tune
  ...

# This XML representation of vCard:
#   <vCard xmlns='vcard-temp'>
#     <FN>Conferences</FN>
#     <ADR>
#       <WORK/>
#       <STREET>Elm Street</STREET>
#     </ADR>
#   </vCard>
#
# is translated to:
vcard:
  fn: Conferences
  adr:
    -
      work: true
      street: Elm Street

Examples:

modules:
  mod_pubsub:
    access_createnode: pubsub_createnode
    max_subscriptions_node: 100
    default_node_config:
      notification_type: normal
      notify_retract: false
      max_items: 4
    plugins:
      - flat
      - pep

modules:
  mod_pubsub:
    db_type: sql
    access_createnode: pubsub_createnode
    ignore_pep_from_offline: true
    last_item_cache: false
    plugins:
      - flat
      - pep

mod_push

This module implements the XMPP server’s part of the push notification solution specified in XEP-0357: Push Notifications. It does not generate, for example, APNS or FCM notifications directly. Instead, it’s designed to work with so-called "app servers" operated by third-party vendors of mobile apps. Those app servers will usually trigger notification delivery to the user’s mobile device using platform-dependent backend services such as FCM or APNS.

Available options:

mod_push_keepalive

This module tries to keep the stream management session (see mod_stream_mgmt) of a disconnected mobile client alive if the client enabled push notifications for that session. However, the normal session resumption timeout is restored once a push notification is issued, so the session will be closed if the client doesn’t respond to push notifications.

The module depends on mod_push.

Available options:

mod_register

This module adds support for XEP-0077: In-Band Registration. This protocol enables end users to use an XMPP client to:

This module reads also the top-level registration_timeout option defined globally for the server, so please check that option documentation too.

Available options:

modules:
  mod_register:
    welcome_message:
      subject: "Welcome!"
      body: |-
        Hi!
        Welcome to this XMPP server

mod_register_web

This module provides a web page where users can:

This module supports basic.md#captcha|CAPTCHA to register a new account. To enable this feature, configure the top-level captcha_cmd and top-level captcha_url options.

As an example usage, the users of the host localhost can visit the page: https://localhost:5280/register/ It is important to include the last / character in the URL, otherwise the subpages URL will be incorrect.

This module is enabled in listen → ejabberd_http → listen-options.md#request_handlers|request_handlers, no need to enable in modules. The module depends on mod_register where all the configuration is performed.

The module has no options.

Example:

listen:
  -
    port: 5280
    module: ejabberd_http
    request_handlers:
      /register: mod_register_web
modules:
  mod_register: {}

mod_roster

This module implements roster management as defined in RFC6121 Section 2. The module also adds support for XEP-0237: Roster Versioning.

Available options:

Example:

modules:
  mod_roster:
    versioning: true
    store_current_id: false

mod_s2s_bidi

Note about this option: added in 24.10.

The module adds support for XEP-0288: Bidirectional Server-to-Server Connections that allows using single s2s connection to communicate in both directions.

The module has no options.

Example:

modules:
  mod_s2s_bidi: {}

mod_s2s_dialback

The module adds support for XEP-0220: Server Dialback to provide server identity verification based on DNS.

Available options:

Example:

modules:
  mod_s2s_dialback:
    access:
      allow:
        server: legacy.domain.tld
        server: invalid-cert.example.org
      deny: all

mod_scram_upgrade

Note about this option: added in 24.10.

The module adds support for XEP-0480: SASL Upgrade Tasks that allows users to upgrade passwords to more secure representation.

Available options:

Example:

modules:
  mod_scram_upgrade:
    offered_upgrades:
      - sha256
      - sha512

mod_service_log

This module forwards copies of all stanzas to remote XMPP servers or components. Every stanza is encapsulated into <forwarded/> element as described in XEP-0297: Stanza Forwarding.

Available options:

Example:

modules:
  mod_service_log:
    loggers:
      - xmpp-server.tld
      - component.domain.tld

mod_shared_roster

This module enables you to create shared roster groups: groups of accounts that can see members from (other) groups in their rosters.

The big advantages of this feature are that end users do not need to manually add all users to their rosters, and that they cannot permanently delete users from the shared roster groups. A shared roster group can have members from any XMPP server, but the presence will only be available from and to members of the same virtual host where the group is created. It still allows the users to have / add their own contacts, as it does not replace the standard roster. Instead, the shared roster contacts are merged to the relevant users at retrieval time. The standard user rosters thus stay unmodified.

Shared roster groups can be edited via the Web Admin, and some API commands called srg_*. Each group has a unique name and those parameters:

This module depends on mod_roster. If not enabled, roster queries will return 503 errors.

Available options:

Examples:

Name: club_members
Label: Club Members
Description: Members from the computer club
Members: member1@example.org, member2@example.org, member3@example.org
Displayed Groups: club_members

First list:
Name: management
Label: Management
Description: Management
Members: manager1@example.org, manager2@example.org
Displayed: management, marketing, sales
Second list:
Name: marketing
Label: Marketing
Description: Marketing
Members: marketeer1@example.org, marketeer2@example.org, marketeer3@example.org
Displayed: management, marketing
Third list:
Name: sales
Label: Sales
Description: Sales
Members: salesman1@example.org, salesman2@example.org, salesman3@example.org
Displayed: management, sales

mod_shared_roster_ldap

This module lets the server administrator automatically populate users' rosters (contact lists) with entries based on users and groups defined in an LDAP-based directory.

The module accepts many configuration options. Some of them, if unspecified, default to the values specified for the top level of configuration. This lets you avoid specifying, for example, the bind password in multiple places.

Check also the ldap.md#ldap-examples|Configuration examples section to get details about retrieving the roster, and configuration examples including Flat DIT and Deep DIT.

Available options:

mod_sic

This module adds support for XEP-0279: Server IP Check. This protocol enables a client to discover its external IP address.

The module has no options.

mod_sip

This module adds SIP proxy/registrar support for the corresponding virtual host.

Available options:

Example:

modules:
  mod_sip:
    always_record_route: false
    record_route: "sip:example.com;lr"
    routes:
      - "sip:example.com;lr"
      - "sip:sip.example.com;lr"
    flow_timeout_udp: 30 sec
    flow_timeout_tcp: 1 min
    via:
      - tls://sip-tls.example.com:5061
      - tcp://sip-tcp.example.com:5060
      - udp://sip-udp.example.com:5060

mod_stats

This module adds support for XEP-0039: Statistics Gathering. This protocol allows you to retrieve the following statistics from your ejabberd server:

The module has no options.

mod_stream_mgmt

This module adds support for XEP-0198: Stream Management. This protocol allows active management of an XML stream between two XMPP entities, including features for stanza acknowledgments and stream resumption.

Available options:

mod_stun_disco

Note about this option: added in 20.04.

This module allows XMPP clients to discover STUN/TURN services and to obtain temporary credentials for using them as per XEP-0215: External Service Discovery.

Available options:

services:
  -
    host: 203.0.113.3
    port: 3478
    type: stun
    transport: udp
    restricted: false
  -
    host: 203.0.113.3
    port: 3478
    type: turn
    transport: udp
    restricted: true
  -
    host: 2001:db8::3
    port: 3478
    type: stun
    transport: udp
    restricted: false
  -
    host: 2001:db8::3
    port: 3478
    type: turn
    transport: udp
    restricted: true
  -
    host: server.example.com
    port: 5349
    type: turns
    transport: tcp
    restricted: true

mod_time

This module adds support for XEP-0202: Entity Time. In other words, the module reports server’s system time.

The module has no options.

mod_vcard

This module allows end users to store and retrieve their vCard, and to retrieve other users vCards, as defined in XEP-0054: vcard-temp. The module also implements an uncomplicated Jabber User Directory based on the vCards of these users. Moreover, it enables the server to send its vCard when queried.

Available options:

# This XML representation of vCard:
#
#   <vCard xmlns='vcard-temp'>
#     <FN>Conferences</FN>
#     <ADR>
#       <WORK/>
#       <STREET>Elm Street</STREET>
#     </ADR>
#   </vCard>
#
# is translated to:
#
vcard:
  fn: Conferences
  adr:
    -
      work: true
      street: Elm Street

Available options for ldap backend:

User: "%u"
"Full Name": displayName
"Given Name": givenName
"Middle Name": initials
"Family Name": sn
Nickname: "%u"
Birthday: birthDay
Country: c
City: l
Email: mail
"Organization Name": o
"Organization Unit": ou

"Full Name": FN
"Given Name": FIRST
"Middle Name": MIDDLE
"Family Name": LAST
"Nickname": NICKNAME
"Birthday": BDAY
"Country": CTRY
"City": LOCALITY
"Email": EMAIL
"Organization Name": ORGNAME
"Organization Unit": ORGUNIT

NICKNAME: {"%u": []}
FN: {"%s": [displayName]}
LAST: {"%s": [sn]}
FIRST: {"%s": [givenName]}
MIDDLE: {"%s": [initials]}
ORGNAME: {"%s": [o]}
ORGUNIT: {"%s": [ou]}
CTRY: {"%s": [c]}
LOCALITY: {"%s": [l]}
STREET: {"%s": [street]}
REGION: {"%s": [st]}
PCODE: {"%s": [postalCode]}
TITLE: {"%s": [title]}
URL: {"%s": [labeleduri]}
DESC: {"%s": [description]}
TEL: {"%s": [telephoneNumber]}
EMAIL: {"%s": [mail]}
BDAY: {"%s": [birthDay]}
ROLE: {"%s": [employeeType]}
PHOTO: {"%s": [jpegPhoto]}

Available options for mnesia backend:

mod_vcard_xupdate

The user’s client can store an avatar in the user vCard. The vCard-Based Avatars protocol (XEP-0153) provides a method for clients to inform the contacts what is the avatar hash value. However, simple or small clients may not implement that protocol.

If this module is enabled, all the outgoing client presence stanzas get automatically the avatar hash on behalf of the client. So, the contacts receive the presence stanzas with the Update Data described in XEP-0153 as if the client would had inserted it itself. If the client had already included such element in the presence stanza, it is replaced with the element generated by ejabberd.

By enabling this module, each vCard modification produces a hash recalculation, and each presence sent by a client produces hash retrieval and a presence stanza rewrite. For this reason, enabling this module will introduce a computational overhead in servers with clients that change frequently their presence. However, the overhead is significantly reduced by the use of caching, so you probably don’t want to set use_cache to false.

The module depends on mod_vcard.

Available options:

mod_version

This module implements XEP-0092: Software Version. Consequently, it answers ejabberd’s version when queried.

Available options: