diff --git a/rootfs/etc/confd/templates/config.yaml.tmpl b/rootfs/etc/confd/templates/config.yaml.tmpl
index 875f4b7..fe5f20f 100644
--- a/rootfs/etc/confd/templates/config.yaml.tmpl
+++ b/rootfs/etc/confd/templates/config.yaml.tmpl
@@ -1,64 +1,64 @@
# Homeserver details.
homeserver:
- # The address that this appservice can use to connect to the homeserver.
- address: "{{ getenv "SERVER_URL" }}"
- # The domain of the homeserver (for MXIDs, etc).
- domain: "{{ getenv "SERVER_DOMAIN" }}"
+ # The address that this appservice can use to connect to the homeserver.
+ address: "{{ getenv "SERVER_URL" }}"
+ # The domain of the homeserver (for MXIDs, etc).
+ domain: "{{ getenv "SERVER_DOMAIN" }}"
- # Is the homeserver actually mautrix-asmux?
- asmux: false
- # The URL to push real-time bridge status to.
- # If set, the bridge will make POST requests to this URL whenever a user's whatsapp connection state changes.
- # The bridge will use the appservice as_token to authorize requests.
- status_endpoint: null
- # Endpoint for reporting per-message status.
- message_send_checkpoint_endpoint: null
- # Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246?
- async_media: false
+ # Is the homeserver actually mautrix-asmux?
+ asmux: false
+ # The URL to push real-time bridge status to.
+ # If set, the bridge will make POST requests to this URL whenever a user's whatsapp connection state changes.
+ # The bridge will use the appservice as_token to authorize requests.
+ status_endpoint: null
+ # Endpoint for reporting per-message status.
+ message_send_checkpoint_endpoint: null
+ # Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246?
+ async_media: false
# Application service host/registration related details.
# Changing these values requires regeneration of the registration.
appservice:
- # The address that the homeserver can use to connect to this appservice.
- address: http://{{getenv "HOSTNAME"}}:29318
+ # The address that the homeserver can use to connect to this appservice.
+ address: http://{{getenv "HOSTNAME"}}:29318
- # The hostname and port where this appservice should listen.
- hostname: 0.0.0.0
- port: 29318
+ # The hostname and port where this appservice should listen.
+ hostname: 0.0.0.0
+ port: 29318
- # Database config.
- database:
- # The database type. Only "sqlite3" is supported.
- type: postgres
- # The database URI. Usually file name. https://github.com/mattn/go-sqlite3#connection-string
- uri: {{ getenv "DATABASE_DATASOURCE" }}
- max_open_conns: 20
- max_idle_conns: 2
- # Maximum connection idle time and lifetime before they're closed. Disabled if null.
- # Parsed with https://pkg.go.dev/time#ParseDuration
- max_conn_idle_time: null
- max_conn_lifetime: null
+ # Database config.
+ database:
+ # The database type. Only "sqlite3" is supported.
+ type: postgres
+ # The database URI. Usually file name. https://github.com/mattn/go-sqlite3#connection-string
+ uri: {{ getenv "DATABASE_DATASOURCE" }}
+ max_open_conns: 20
+ max_idle_conns: 2
+ # Maximum connection idle time and lifetime before they're closed. Disabled if null.
+ # Parsed with https://pkg.go.dev/time#ParseDuration
+ max_conn_idle_time: null
+ max_conn_lifetime: null
- # The unique ID of this appservice.
- id: whatsapp
- # Appservice bot details.
- bot:
- # Username of the appservice bot.
- username: whatsappbot
- # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
- # to leave display name/avatar as-is.
- displayname: WhatsApp bridge bot
- avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr
+ # The unique ID of this appservice.
+ id: whatsapp
+ # Appservice bot details.
+ bot:
+ # Username of the appservice bot.
+ username: whatsappbot
+ # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
+ # to leave display name/avatar as-is.
+ displayname: WhatsApp bridge bot
+ avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr
- # Whether or not to receive ephemeral events via appservice transactions.
- # Requires MSC2409 support (i.e. Synapse 1.22+).
- # You should disable bridge -> sync_with_custom_puppets when this is enabled.
- ephemeral_events: false
+ # Whether or not to receive ephemeral events via appservice transactions.
+ # Requires MSC2409 support (i.e. Synapse 1.22+).
+ # You should disable bridge -> sync_with_custom_puppets when this is enabled.
+ ephemeral_events: false
- # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
- as_token: "{{ getenv "AS_TOKEN" }}"
- hs_token: "{{ getenv "HS_TOKEN" }}"
+ # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
+ as_token: "{{ getenv "AS_TOKEN" }}"
+ hs_token: "{{ getenv "HS_TOKEN" }}"
# Prometheus config.
metrics:
@@ -78,319 +78,312 @@ whatsapp:
# Bridge config
bridge:
- # Localpart template of MXIDs for WhatsApp users.
- # {{.}} is replaced with the phone number of the WhatsApp user.
- username_template: whatsapp_{{"{{"}}.{{"}}"}}
- # Displayname template for WhatsApp users.
- # {{.PushName}} - nickname set by the WhatsApp user
- # {{.BusinessName}} - validated WhatsApp business name
- # {{.Phone}} - phone number (international format)
- # The following variables are also available, but will cause problems on multi-user instances:
- # {{.FullName}} - full name from contact list
- # {{.FirstName}} - first name from contact list
- displayname_template: "{{"{{"}}if .PushName{{"}}"}}{{"{{"}}.PushName{{"}}"}}{{"{{"}}else if .BusinessName{{"}}"}}{{"{{"}}.BusinessName{{"}}"}}{{"{{"}}else{{"}}"}}{{"{{"}}.JID{{"}}"}}{{"{{"}}end{{"}}"}} (WA)"
- # Should the bridge create a space for each logged-in user and add bridged rooms to it?
- # Users who logged in before turning this on should run `!wa sync space` to create and fill the space for the first time.
- personal_filtering_spaces: false
- # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
- delivery_receipts: false
- # Whether the bridge should send the message status as a custom com.beeper.message_send_status event.
- message_status_events: false
- # Whether the bridge should send error notices via m.notice events when a message fails to bridge.
- message_error_notices: true
- # Should incoming calls send a message to the Matrix room?
- call_start_notices: true
- # Should another user's cryptographic identity changing send a message to Matrix?
- identity_change_notices: false
- portal_message_buffer: 128
- # Settings for handling history sync payloads. These settings only apply right after login,
- # because the phone only sends the history sync data once, and there's no way to re-request it
- # (other than logging out and back in again).
- history_sync:
- # Should the bridge create portals for chats in the history sync payload?
- create_portals: true
- # Enable backfilling history sync payloads from WhatsApp using batch sending?
- # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
- # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
- # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
- # There are also still some issues in Synapse's federation implementation.
- backfill: false
- # Use double puppets for backfilling?
- # In order to use this, the double puppets must be in the appservice's user ID namespace
- # (because the bridge can't use the double puppet access token with batch sending).
- # This only affects double puppets on the local server, double puppets on other servers will never be used.
- double_puppet_backfill: false
- # Should the bridge request a full sync from the phone when logging in?
- # This bumps the size of history syncs from 3 months to 1 year.
- request_full_sync: false
- # Settings for media requests. If the media expired, then it will not
- # be on the WA servers.
- # Media can always be requested by reacting with the ♻️ (recycle) emoji.
- # These settings determine if the media requests should be done
- # automatically during or after backfill.
- media_requests:
- # Should expired media be automatically requested from the server as
- # part of the backfill process?
- auto_request_media: true
- # Whether to request the media immediately after the media message
- # is backfilled ("immediate") or at a specific time of the day
- # ("local_time").
- request_method: immediate
- # If request_method is "local_time", what time should the requests
- # be sent (in minutes after midnight)?
- request_local_time: 120
- # The maximum number of initial conversations that should be synced.
- # Other conversations will be backfilled on demand when the start PM
- # provisioning endpoint is used or when a message comes in from that
- # chat.
- max_initial_conversations: -1
- # Settings for immediate backfills. These backfills should generally be
- # small and their main purpose is to populate each of the initial chats
- # (as configured by max_initial_conversations) with a few messages so
- # that you can continue conversations without loosing context.
- immediate:
- # The number of concurrent backfill workers to create for immediate
- # backfills. Note that using more than one worker could cause the
- # room list to jump around since there are no guarantees about the
- # order in which the backfills will complete.
- worker_count: 1
- # The maximum number of events to backfill initially.
- max_events: 10
- # Settings for deferred backfills. The purpose of these backfills are
- # to fill in the rest of the chat history that was not covered by the
- # immediate backfills. These backfills generally should happen at a
- # slower pace so as not to overload the homeserver.
- # Each deferred backfill config should define a "stage" of backfill
- # (i.e. the last week of messages). The fields are as follows:
- # - start_days_ago: the number of days ago to start backfilling from.
- # To indicate the start of time, use -1. For example, for a week ago, use 7.
- # - max_batch_events: the number of events to send per batch.
- # - batch_delay: the number of seconds to wait before backfilling each batch.
- deferred:
- # Last Week
- - start_days_ago: 7
- max_batch_events: 20
- batch_delay: 5
- # Last Month
- - start_days_ago: 30
- max_batch_events: 50
- batch_delay: 10
- # Last 3 months
- - start_days_ago: 90
- max_batch_events: 100
- batch_delay: 10
- # The start of time
- - start_days_ago: -1
- max_batch_events: 500
- batch_delay: 10
- # Should puppet avatars be fetched from the server even if an avatar is already set?
- user_avatar_sync: true
- # Should Matrix users leaving groups be bridged to WhatsApp?
- bridge_matrix_leave: true
- # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
- sync_with_custom_puppets: true
- # Should the bridge update the m.direct account data event when double puppeting is enabled.
- # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
- # and is therefore prone to race conditions.
- sync_direct_chat_list: false
- # Should the bridge use MSC2867 to bridge manual "mark as unread"s from
- # WhatsApp and set the unread status on initial backfill?
- # This will only work on clients that support the m.marked_unread or
- # com.famedly.marked_unread room account data.
- sync_manual_marked_unread: true
- # When double puppeting is enabled, users can use `!wa toggle` to change whether
- # presence and read receipts are bridged. These settings set the default values.
- # Existing users won't be affected when these are changed.
- default_bridge_receipts: true
- default_bridge_presence: true
- # Send the presence as "available" to whatsapp when users start typing on a portal.
- # This works as a workaround for homeservers that do not support presence, and allows
- # users to see when the whatsapp user on the other side is typing during a conversation.
- send_presence_on_typing: false
- # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)
- # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?
- #
- # By default, the bridge acts like WhatsApp web, which only sends active delivery
- # receipts when it's in the foreground.
- force_active_delivery_receipts: false
- # Servers to always allow double puppeting from
- double_puppet_server_map:
- example.com: https://example.com
- # Allow using double puppeting from any server with a valid client .well-known file.
- double_puppet_allow_discovery: false
- # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth
- #
- # If set, double puppeting will be enabled automatically for local users
- # instead of users having to find an access token and run `login-matrix`
- # manually.
- login_shared_secret_map:
- example.com: foobar
- # Should the bridge explicitly set the avatar and room name for private chat portal rooms?
- private_chat_portal_meta: false
- # Should Matrix m.notice-type messages be bridged?
- bridge_notices: true
- # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
- # This field will automatically be changed back to false after it, except if the config file is not writable.
- resend_bridge_info: false
- # When using double puppeting, should muted chats be muted in Matrix?
- mute_bridging: false
- # When using double puppeting, should archived chats be moved to a specific tag in Matrix?
- # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.
- # This can be set to a tag (e.g. m.lowpriority), or null to disable.
- archive_tag: null
- # Same as above, but for pinned chats. The favorite tag is called m.favourite
- pinned_tag: null
- # Should mute status and tags only be bridged when the portal room is created?
- tag_only_on_create: true
- # Should WhatsApp status messages be bridged into a Matrix room?
- # Disabling this won't affect already created status broadcast rooms.
- enable_status_broadcast: true
- # Should sending WhatsApp status messages be allowed?
- # This can cause issues if the user has lots of contacts, so it's disabled by default.
- disable_status_broadcast_send: true
- # Should the status broadcast room be muted and moved into low priority by default?
- # This is only applied when creating the room, the user can unmute/untag it later.
- mute_status_broadcast: true
- # Tag to apply to the status broadcast room.
- status_broadcast_tag: m.lowpriority
- # Should the bridge use thumbnails from WhatsApp?
- # They're disabled by default due to very low resolution.
- whatsapp_thumbnail: false
- # Allow invite permission for user. User can invite any bots to room with whatsapp
- # users (private chat and groups)
- allow_user_invite: false
- # Whether or not created rooms should have federation enabled.
- # If false, created portal rooms will never be federated.
- federate_rooms: true
- # Whether to enable disappearing messages in groups. If enabled, then the expiration time of
- # the messages will be determined by the first user to read the message, rather than individually.
- # If the bridge only has a single user, this can be turned on safely.
- disappearing_messages_in_groups: false
- # Should the bridge never send alerts to the bridge management room?
- # These are mostly things like the user being logged out.
- disable_bridge_alerts: false
- # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,
- # and send it to WhatsApp? URL previews can always be sent using the `com.beeper.linkpreviews`
- # key in the event content even if this is disabled.
- url_previews: false
- # Send captions in the same message as images. This will send data compatible with both MSC2530 and MSC3552.
- # This is currently not supported in most clients.
- caption_in_message: false
- # Maximum time for handling Matrix events. Duration strings formatted for https://pkg.go.dev/time#ParseDuration
- # Null means there's no enforced timeout.
- message_handling_timeout:
- # Send an error message after this timeout, but keep waiting for the response until the deadline.
- # This is counted from the origin_server_ts, so the warning time is consistent regardless of the source of delay.
- # If the message is older than this when it reaches the bridge, the message won't be handled at all.
- error_after: null
- # Drop messages after this timeout. They may still go through if the message got sent to the servers.
- # This is counted from the time the bridge starts handling the message.
- deadline: 120s
+ # Localpart template of MXIDs for WhatsApp users.
+ username_template: whatsapp_{{"{{"}}.{{"}}"}}
+ # Displayname template for WhatsApp users.
+ displayname_template: "{{"{{"}}if .PushName{{"}}"}}{{"{{"}}.PushName{{"}}"}}{{"{{"}}else if .BusinessName{{"}}"}}{{"{{"}}.BusinessName{{"}}"}}{{"{{"}}else{{"}}"}}{{"{{"}}.JID{{"}}"}}{{"{{"}}end{{"}}"}} (WA)"
+ # Should the bridge create a space for each logged-in user and add bridged rooms to it?
+ # Users who logged in before turning this on should run `!wa sync space` to create and fill the space for the first time.
+ personal_filtering_spaces: false
+ # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
+ delivery_receipts: false
+ # Whether the bridge should send the message status as a custom com.beeper.message_send_status event.
+ message_status_events: false
+ # Whether the bridge should send error notices via m.notice events when a message fails to bridge.
+ message_error_notices: true
+ # Should incoming calls send a message to the Matrix room?
+ call_start_notices: true
+ # Should another user's cryptographic identity changing send a message to Matrix?
+ identity_change_notices: false
+ portal_message_buffer: 128
+ # Settings for handling history sync payloads. These settings only apply right after login,
+ # because the phone only sends the history sync data once, and there's no way to re-request it
+ # (other than logging out and back in again).
+ history_sync:
+ # Should the bridge create portals for chats in the history sync payload?
+ create_portals: true
+ # Enable backfilling history sync payloads from WhatsApp using batch sending?
+ # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
+ # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
+ # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
+ # There are also still some issues in Synapse's federation implementation.
+ backfill: false
+ # Use double puppets for backfilling?
+ # In order to use this, the double puppets must be in the appservice's user ID namespace
+ # (because the bridge can't use the double puppet access token with batch sending).
+ # This only affects double puppets on the local server, double puppets on other servers will never be used.
+ double_puppet_backfill: false
+ # Should the bridge request a full sync from the phone when logging in?
+ # This bumps the size of history syncs from 3 months to 1 year.
+ request_full_sync: false
+ # Settings for media requests. If the media expired, then it will not
+ # be on the WA servers.
+ # Media can always be requested by reacting with the ♻️ (recycle) emoji.
+ # These settings determine if the media requests should be done
+ # automatically during or after backfill.
+ media_requests:
+ # Should expired media be automatically requested from the server as
+ # part of the backfill process?
+ auto_request_media: true
+ # Whether to request the media immediately after the media message
+ # is backfilled ("immediate") or at a specific time of the day
+ # ("local_time").
+ request_method: immediate
+ # If request_method is "local_time", what time should the requests
+ # be sent (in minutes after midnight)?
+ request_local_time: 120
+ # The maximum number of initial conversations that should be synced.
+ # Other conversations will be backfilled on demand when the start PM
+ # provisioning endpoint is used or when a message comes in from that
+ # chat.
+ max_initial_conversations: -1
+ # Settings for immediate backfills. These backfills should generally be
+ # small and their main purpose is to populate each of the initial chats
+ # (as configured by max_initial_conversations) with a few messages so
+ # that you can continue conversations without loosing context.
+ immediate:
+ # The number of concurrent backfill workers to create for immediate
+ # backfills. Note that using more than one worker could cause the
+ # room list to jump around since there are no guarantees about the
+ # order in which the backfills will complete.
+ worker_count: 1
+ # The maximum number of events to backfill initially.
+ max_events: 10
+ # Settings for deferred backfills. The purpose of these backfills are
+ # to fill in the rest of the chat history that was not covered by the
+ # immediate backfills. These backfills generally should happen at a
+ # slower pace so as not to overload the homeserver.
+ # Each deferred backfill config should define a "stage" of backfill
+ # (i.e. the last week of messages). The fields are as follows:
+ # - start_days_ago: the number of days ago to start backfilling from.
+ # To indicate the start of time, use -1. For example, for a week ago, use 7.
+ # - max_batch_events: the number of events to send per batch.
+ # - batch_delay: the number of seconds to wait before backfilling each batch.
+ deferred:
+ # Last Week
+ - start_days_ago: 7
+ max_batch_events: 20
+ batch_delay: 5
+ # Last Month
+ - start_days_ago: 30
+ max_batch_events: 50
+ batch_delay: 10
+ # Last 3 months
+ - start_days_ago: 90
+ max_batch_events: 100
+ batch_delay: 10
+ # The start of time
+ - start_days_ago: -1
+ max_batch_events: 500
+ batch_delay: 10
+ # Should puppet avatars be fetched from the server even if an avatar is already set?
+ user_avatar_sync: true
+ # Should Matrix users leaving groups be bridged to WhatsApp?
+ bridge_matrix_leave: true
+ # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
+ sync_with_custom_puppets: true
+ # Should the bridge update the m.direct account data event when double puppeting is enabled.
+ # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
+ # and is therefore prone to race conditions.
+ sync_direct_chat_list: false
+ # Should the bridge use MSC2867 to bridge manual "mark as unread"s from
+ # WhatsApp and set the unread status on initial backfill?
+ # This will only work on clients that support the m.marked_unread or
+ # com.famedly.marked_unread room account data.
+ sync_manual_marked_unread: true
+ # When double puppeting is enabled, users can use `!wa toggle` to change whether
+ # presence and read receipts are bridged. These settings set the default values.
+ # Existing users won't be affected when these are changed.
+ default_bridge_receipts: true
+ default_bridge_presence: true
+ # Send the presence as "available" to whatsapp when users start typing on a portal.
+ # This works as a workaround for homeservers that do not support presence, and allows
+ # users to see when the whatsapp user on the other side is typing during a conversation.
+ send_presence_on_typing: false
+ # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)
+ # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?
+ #
+ # By default, the bridge acts like WhatsApp web, which only sends active delivery
+ # receipts when it's in the foreground.
+ force_active_delivery_receipts: false
+ # Servers to always allow double puppeting from
+ double_puppet_server_map:
+ example.com: https://example.com
+ # Allow using double puppeting from any server with a valid client .well-known file.
+ double_puppet_allow_discovery: false
+ # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth
+ #
+ # If set, double puppeting will be enabled automatically for local users
+ # instead of users having to find an access token and run `login-matrix`
+ # manually.
+ login_shared_secret_map:
+ example.com: foobar
+ # Should the bridge explicitly set the avatar and room name for private chat portal rooms?
+ private_chat_portal_meta: false
+ # Should Matrix m.notice-type messages be bridged?
+ bridge_notices: true
+ # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
+ # This field will automatically be changed back to false after it, except if the config file is not writable.
+ resend_bridge_info: false
+ # When using double puppeting, should muted chats be muted in Matrix?
+ mute_bridging: false
+ # When using double puppeting, should archived chats be moved to a specific tag in Matrix?
+ # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.
+ # This can be set to a tag (e.g. m.lowpriority), or null to disable.
+ archive_tag: null
+ # Same as above, but for pinned chats. The favorite tag is called m.favourite
+ pinned_tag: null
+ # Should mute status and tags only be bridged when the portal room is created?
+ tag_only_on_create: true
+ # Should WhatsApp status messages be bridged into a Matrix room?
+ # Disabling this won't affect already created status broadcast rooms.
+ enable_status_broadcast: true
+ # Should sending WhatsApp status messages be allowed?
+ # This can cause issues if the user has lots of contacts, so it's disabled by default.
+ disable_status_broadcast_send: true
+ # Should the status broadcast room be muted and moved into low priority by default?
+ # This is only applied when creating the room, the user can unmute/untag it later.
+ mute_status_broadcast: true
+ # Tag to apply to the status broadcast room.
+ status_broadcast_tag: m.lowpriority
+ # Should the bridge use thumbnails from WhatsApp?
+ # They're disabled by default due to very low resolution.
+ whatsapp_thumbnail: false
+ # Allow invite permission for user. User can invite any bots to room with whatsapp
+ # users (private chat and groups)
+ allow_user_invite: false
+ # Whether or not created rooms should have federation enabled.
+ # If false, created portal rooms will never be federated.
+ federate_rooms: true
+ # Whether to enable disappearing messages in groups. If enabled, then the expiration time of
+ # the messages will be determined by the first user to read the message, rather than individually.
+ # If the bridge only has a single user, this can be turned on safely.
+ disappearing_messages_in_groups: false
+ # Should the bridge never send alerts to the bridge management room?
+ # These are mostly things like the user being logged out.
+ disable_bridge_alerts: false
+ # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,
+ # and send it to WhatsApp? URL previews can always be sent using the `com.beeper.linkpreviews`
+ # key in the event content even if this is disabled.
+ url_previews: false
+ # Send captions in the same message as images. This will send data compatible with both MSC2530 and MSC3552.
+ # This is currently not supported in most clients.
+ caption_in_message: false
+ # Maximum time for handling Matrix events. Duration strings formatted for https://pkg.go.dev/time#ParseDuration
+ # Null means there's no enforced timeout.
+ message_handling_timeout:
+ # Send an error message after this timeout, but keep waiting for the response until the deadline.
+ # This is counted from the origin_server_ts, so the warning time is consistent regardless of the source of delay.
+ # If the message is older than this when it reaches the bridge, the message won't be handled at all.
+ error_after: null
+ # Drop messages after this timeout. They may still go through if the message got sent to the servers.
+ # This is counted from the time the bridge starts handling the message.
+ deadline: 120s
- # The prefix for commands. Only required in non-management rooms.
- command_prefix: "!wa"
+ # The prefix for commands. Only required in non-management rooms.
+ command_prefix: "!wa"
- # Messages sent upon joining a management room.
- # Markdown is supported. The defaults are listed below.
- management_room_text:
- # Sent when joining a room.
- welcome: "Hello, I'm a WhatsApp bridge bot."
- # Sent when joining a management room and the user is already logged in.
- welcome_connected: "Use `help` for help."
- # Sent when joining a management room and the user is not logged in.
- welcome_unconnected: "Use `help` for help or `login` to log in."
- # Optional extra text sent when joining a management room.
- additional_help: ""
+ # Messages sent upon joining a management room.
+ # Markdown is supported. The defaults are listed below.
+ management_room_text:
+ # Sent when joining a room.
+ welcome: "Hello, I'm a WhatsApp bridge bot."
+ # Sent when joining a management room and the user is already logged in.
+ welcome_connected: "Use `help` for help."
+ # Sent when joining a management room and the user is not logged in.
+ welcome_unconnected: "Use `help` for help or `login` to log in."
+ # Optional extra text sent when joining a management room.
+ additional_help: ""
- # End-to-bridge encryption support options.
- #
- # See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html for more info.
- encryption:
- # Allow encryption, work in group chat rooms with e2ee enabled
- allow: true
- # Default to encryption, force-enable encryption in all portals the bridge creates
- # This will cause the bridge bot to be in private chats for the encryption to work properly.
- # It is recommended to also set private_chat_portal_meta to true when using this.
- default: true
- # Require encryption, drop any unencrypted messages.
- require: false
- # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
- # You must use a client that supports requesting keys from other users to use this feature.
- allow_key_sharing: false
- # What level of device verification should be required from users?
- #
- # Valid levels:
- # unverified - Send keys to all device in the room.
- # cross-signed-untrusted - Require valid cross-signing, but trust all cross-signing keys.
- # cross-signed-tofu - Require valid cross-signing, trust cross-signing keys on first use (and reject changes).
- # cross-signed-verified - Require valid cross-signing, plus a valid user signature from the bridge bot.
- # Note that creating user signatures from the bridge bot is not currently possible.
- # verified - Require manual per-device verification
- # (currently only possible by modifying the `trust` column in the `crypto_device` database table).
- verification_levels:
- # Minimum level for which the bridge should send keys to when bridging messages from WhatsApp to Matrix.
- receive: unverified
- # Minimum level that the bridge should accept for incoming Matrix messages.
- send: unverified
- # Minimum level that the bridge should require for accepting key requests.
- share: cross-signed-tofu
- # Options for Megolm room key rotation. These options allow you to
- # configure the m.room.encryption event content. See:
- # https://spec.matrix.org/v1.3/client-server-api/#mroomencryption for
- # more information about that event.
- rotation:
- # Enable custom Megolm room key rotation settings. Note that these
- # settings will only apply to rooms created after this option is
- # set.
- enable_custom: false
- # The maximum number of milliseconds a session should be used
- # before changing it. The Matrix spec recommends 604800000 (a week)
- # as the default.
- milliseconds: 604800000
- # The maximum number of messages that should be sent with a given a
- # session before changing it. The Matrix spec recommends 100 as the
- # default.
- messages: 100
+ # End-to-bridge encryption support options.
+ #
+ # See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html for more info.
+ encryption:
+ # Allow encryption, work in group chat rooms with e2ee enabled
+ allow: true
+ # Default to encryption, force-enable encryption in all portals the bridge creates
+ # This will cause the bridge bot to be in private chats for the encryption to work properly.
+ # It is recommended to also set private_chat_portal_meta to true when using this.
+ default: true
+ # Require encryption, drop any unencrypted messages.
+ require: false
+ # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
+ # You must use a client that supports requesting keys from other users to use this feature.
+ allow_key_sharing: false
+ # What level of device verification should be required from users?
+ #
+ # Valid levels:
+ # unverified - Send keys to all device in the room.
+ # cross-signed-untrusted - Require valid cross-signing, but trust all cross-signing keys.
+ # cross-signed-tofu - Require valid cross-signing, trust cross-signing keys on first use (and reject changes).
+ # cross-signed-verified - Require valid cross-signing, plus a valid user signature from the bridge bot.
+ # Note that creating user signatures from the bridge bot is not currently possible.
+ # verified - Require manual per-device verification
+ # (currently only possible by modifying the `trust` column in the `crypto_device` database table).
+ verification_levels:
+ # Minimum level for which the bridge should send keys to when bridging messages from WhatsApp to Matrix.
+ receive: unverified
+ # Minimum level that the bridge should accept for incoming Matrix messages.
+ send: unverified
+ # Minimum level that the bridge should require for accepting key requests.
+ share: cross-signed-tofu
+ # Options for Megolm room key rotation. These options allow you to
+ # configure the m.room.encryption event content. See:
+ # https://spec.matrix.org/v1.3/client-server-api/#mroomencryption for
+ # more information about that event.
+ rotation:
+ # Enable custom Megolm room key rotation settings. Note that these
+ # settings will only apply to rooms created after this option is
+ # set.
+ enable_custom: false
+ # The maximum number of milliseconds a session should be used
+ # before changing it. The Matrix spec recommends 604800000 (a week)
+ # as the default.
+ milliseconds: 604800000
+ # The maximum number of messages that should be sent with a given a
+ # session before changing it. The Matrix spec recommends 100 as the
+ # default.
+ messages: 100
- # Settings for provisioning API
- provisioning:
- # Prefix for the provisioning API paths.
- prefix: /_matrix/provision
- # Shared secret for authentication. If set to "generate", a random secret will be generated,
- # or if set to "disable", the provisioning API will be disabled.
- shared_secret: generate
+ # Settings for provisioning API
+ provisioning:
+ # Prefix for the provisioning API paths.
+ prefix: /_matrix/provision
+ # Shared secret for authentication. If set to "generate", a random secret will be generated,
+ # or if set to "disable", the provisioning API will be disabled.
+ shared_secret: generate
- # Permissions for using the bridge.
- # Permitted values:
- # user - Access to use the bridge to chat with a WhatsApp account.
- # admin - User level and some additional administration tools
- # Permitted keys:
- # * - All Matrix users
- # domain - All users on that homeserver
- # mxid - Specific user
- permissions:
- "*": relay
- "{{ getenv "SERVER_DOMAIN" }}": user
- "{{ getenv "ADMIN_USER" }}": admin
+ # Permissions for using the bridge.
+ # Permitted values:
+ # user - Access to use the bridge to chat with a WhatsApp account.
+ # admin - User level and some additional administration tools
+ # Permitted keys:
+ # * - All Matrix users
+ # domain - All users on that homeserver
+ # mxid - Specific user
+ permissions:
+ "*": relay
+ "{{ getenv "SERVER_DOMAIN" }}": user
+ "{{ getenv "ADMIN_USER" }}": admin
- # Settings for relay mode
- relay:
- # Whether relay mode should be allowed. If allowed, `!wa set-relay` can be used to turn any
- # authenticated user into a relaybot for that chat.
- enabled: false
- # Should only admins be allowed to set themselves as relay users?
- admin_only: true
- # The formats to use when sending messages to WhatsApp via the relaybot.
- message_formats:
- m.text: "{{"{{"}} .Sender.Displayname {{"}}"}}: {{"{{"}} .Message {{"}}"}}"
- m.notice: "{{"{{"}} .Sender.Displayname {{"}}"}}: {{"{{"}} .Message {{"}}"}}"
- m.emote: "* {{"{{"}} .Sender.Displayname {{"}}"}} {{"{{"}} .Message {{"}}"}}"
- m.file: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a file"
- m.image: "{{"{{"}} .Sender.Displayname {{"}}"}} sent an image"
- m.audio: "{{"{{"}} .Sender.Displayname {{"}}"}} sent an audio file"
- m.video: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a video"
- m.location: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a location"
+ # Settings for relay mode
+ relay:
+ # Whether relay mode should be allowed. If allowed, `!wa set-relay` can be used to turn any
+ # authenticated user into a relaybot for that chat.
+ enabled: false
+ # Should only admins be allowed to set themselves as relay users?
+ admin_only: true
+ # The formats to use when sending messages to WhatsApp via the relaybot.
+ message_formats:
+ m.text: "{{"{{"}} .Sender.Displayname {{"}}"}}: {{"{{"}} .Message {{"}}"}}"
+ m.notice: "{{"{{"}} .Sender.Displayname {{"}}"}}: {{"{{"}} .Message {{"}}"}}"
+ m.emote: "* {{"{{"}} .Sender.Displayname {{"}}"}} {{"{{"}} .Message {{"}}"}}"
+ m.file: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a file"
+ m.image: "{{"{{"}} .Sender.Displayname {{"}}"}} sent an image"
+ m.audio: "{{"{{"}} .Sender.Displayname {{"}}"}} sent an audio file"
+ m.video: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a video"
+ m.location: "{{"{{"}} .Sender.Displayname {{"}}"}} sent a location"
# Logging config.
logging:
@@ -408,4 +401,4 @@ logging:
# Minimum severity for log messages printed to stdout/stderr. This doesn't affect the log file.
# Options: debug, info, warn, error, fatal
print_level: debug
-
+