Merge pull request #1400 from IUCCA/master

Updated Mautrix-WhatsApp config
This commit is contained in:
Slavi Pantaleev 2021-11-16 15:50:06 +02:00 committed by GitHub
commit 5fc533eca5
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 152 additions and 77 deletions

View file

@ -8,8 +8,25 @@ Use the following playbook configuration:
```yaml ```yaml
matrix_mautrix_whatsapp_enabled: true matrix_mautrix_whatsapp_enabled: true
``` ```
Whatsapp multidevice beta is required, now it is enough if Whatsapp is connected to the Internet every 2 weeks.
## Enable backfilling history
This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
Note that as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
Use the following playbook configuration:
```yaml
matrix_synapse_configuration_extension_yaml: |
experimental_features:
msc2716_enabled: true
```
```yaml
matrix_mautrix_whatsapp_configuration_extension_yaml:
bridge:
history_sync:
backfill: true
```
## Set up Double Puppeting ## Set up Double Puppeting

View file

@ -36,7 +36,6 @@ matrix_mautrix_whatsapp_homeserver_token: ''
matrix_mautrix_whatsapp_appservice_bot_username: whatsappbot matrix_mautrix_whatsapp_appservice_bot_username: whatsappbot
# Database-related configuration fields. # Database-related configuration fields.
# #
# To use SQLite, stick to these defaults. # To use SQLite, stick to these defaults.
@ -71,9 +70,14 @@ matrix_mautrix_whatsapp_appservice_database_uri: "{{
}[matrix_mautrix_whatsapp_database_engine] }[matrix_mautrix_whatsapp_database_engine]
}}" }}"
# Can be set to enable automatic double-puppeting via Shared Secret Auth (https://github.com/devture/matrix-synapse-shared-secret-auth). # Can be set to enable automatic double-puppeting via Shared Secret Auth (https://github.com/devture/matrix-synapse-shared-secret-auth).
matrix_mautrix_whatsapp_login_shared_secret: '' matrix_mautrix_whatsapp_login_shared_secret: ''
matrix_mautrix_whatsapp_bridge_login_shared_secret_map:
"{{ {matrix_mautrix_whatsapp_homeserver_domain: matrix_mautrix_whatsapp_login_shared_secret} if matrix_mautrix_whatsapp_login_shared_secret else {} }}"
# Servers to always allow double puppeting from
matrix_mautrix_whatsapp_bridge_double_puppet_server_map:
"{{ matrix_mautrix_whatsapp_homeserver_domain : matrix_mautrix_whatsapp_homeserver_address }}"
# Default mautrix-whatsapp configuration template which covers the generic use case. # Default mautrix-whatsapp configuration template which covers the generic use case.
# You can customize it by controlling the various variables inside it. # You can customize it by controlling the various variables inside it.

View file

@ -7,15 +7,17 @@ homeserver:
domain: {{ matrix_mautrix_whatsapp_homeserver_domain }} domain: {{ matrix_mautrix_whatsapp_homeserver_domain }}
# Application service host/registration related details. # Application service host/registration related details.
# Changing these values requires regeneration of the registration. # Changing these values requires regeneration of the registration.
# 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"
appservice: appservice:
# The address that the homeserver can use to connect to this appservice. # The address that the homeserver can use to connect to this appservice.
address: {{ matrix_mautrix_whatsapp_appservice_address }} address: {{ matrix_mautrix_whatsapp_appservice_address }}
# The hostname and port where this appservice should listen. # The hostname and port where this appservice should listen.
hostname: 0.0.0.0 hostname: 0.0.0.0
port: 8080 port: 8080
# Database config. # Database config.
database: database:
# The database type. "sqlite3" and "postgres" are supported. # The database type. "sqlite3" and "postgres" are supported.
@ -27,10 +29,6 @@ appservice:
# Maximum number of connections. Mostly relevant for Postgres. # Maximum number of connections. Mostly relevant for Postgres.
max_open_conns: 20 max_open_conns: 20
max_idle_conns: 2 max_idle_conns: 2
# Path to the Matrix room state store.
state_store_path: ./mx-state.json
# The unique ID of this appservice. # The unique ID of this appservice.
id: whatsapp id: whatsapp
# Appservice bot details. # Appservice bot details.
@ -41,7 +39,6 @@ appservice:
# to leave display name/avatar as-is. # to leave display name/avatar as-is.
displayname: WhatsApp bridge bot displayname: WhatsApp bridge bot
avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr
# Authentication tokens for AS <-> HS communication. Autogenerated; do not modify. # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
as_token: "{{ matrix_mautrix_whatsapp_appservice_token }}" as_token: "{{ matrix_mautrix_whatsapp_appservice_token }}"
hs_token: "{{ matrix_mautrix_whatsapp_homeserver_token }}" hs_token: "{{ matrix_mautrix_whatsapp_homeserver_token }}"
@ -51,79 +48,137 @@ bridge:
# Localpart template of MXIDs for WhatsApp users. # Localpart template of MXIDs for WhatsApp users.
# {{ '{{.}}' }} is replaced with the phone number of the WhatsApp user. # {{ '{{.}}' }} is replaced with the phone number of the WhatsApp user.
username_template: "{{ 'whatsapp_{{.}}' }}" username_template: "{{ 'whatsapp_{{.}}' }}"
# Displayname template for WhatsApp users. displayname_template: "{{ '{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)' }}"
# {{ '{{.Notify'}}' }} - nickname set by the WhatsApp user # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
# {{ '{{.Jid}}' }} - phone number (international format) delivery_receipts: false
# The following variables are also available, but will cause problems on multi-user instances: # Should incoming calls send a message to the Matrix room?
# {{ '{{.Name}}' }} - display name from contact list call_start_notices: true
# {{ '{{.Short}}' }} - short display name from contact list # Should another user's cryptographic identity changing send a message to Matrix?
displayname_template: "{{ '{{if .Notify}}{{.Notify}}{{else}}{{.Jid}}{{end}} (WA)' }}" identity_change_notices: false
# WhatsApp connection timeout in seconds. # Should a "reactions not yet supported" warning be sent to the Matrix room when a user reacts to a message?
connection_timeout: 20 reaction_notices: true
# Maximum number of times to retry connecting on connection error. portal_message_buffer: 128
max_connection_attempts: 3 # Settings for handling history sync payloads. These settings only apply right after login,
# Number of seconds to wait between connection attempts. # because the phone only sends the history sync data once, and there's no way to re-request it
# Negative numbers are exponential backoff: -connection_retry_delay + 1 + 2^attempts # (other than logging out and back in again).
connection_retry_delay: -1 history_sync:
# Whether or not the bridge should send a notice to the user's management room when it retries connecting. # Should the bridge create portals for chats in the history sync payload?
# If false, it will only report when it stops retrying. create_portals: true
report_connection_retry: true # Maximum age of chats in seconds to create portals for. Set to 0 to create portals for all chats in sync payload.
# Maximum number of seconds to wait for chats to be sent at startup. max_age: 604800
# If this is too low and you have lots of chats, it could cause backfilling to fail. # Enable backfilling history sync payloads from WhatsApp using batch sending?
chat_list_wait: 30 # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
# Maximum number of seconds to wait to sync portals before force unlocking message processing. # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
# If this is too low and you have lots of chats, it could cause backfilling to fail. # Note that as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
portal_sync_wait: 600 backfill: false
# Use double puppets for backfilling?
# Whether or not to send call start/end notices to Matrix. # In order to use this, the double puppets must be in the appservice's user ID namespace
call_notices: # (because the bridge can't use the double puppet access token with batch sending).
start: true # This only affects double puppets on the local server, double puppets on other servers will never be used.
end: true # Doesn't work out of box with this playbook
double_puppet_backfill: false
# Number of chats to sync for new users. # Should the bridge request a full sync from the phone when logging in?
initial_chat_sync_count: 10 # This bumps the size of history syncs from 3 months to 1 year.
# Number of old messages to fill when creating new portal rooms. request_full_sync: false
initial_history_fill_count: 20 user_avatar_sync: true
# Maximum number of chats to sync when recovering from downtime. # Should Matrix users leaving groups be bridged to WhatsApp?
# Set to -1 to sync all new chats during downtime. bridge_matrix_leave: true
recovery_chat_sync_limit: -1 # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
# Whether or not to sync history when recovering from downtime.
recovery_history_backfill: true
# Maximum number of seconds since last message in chat to skip
# syncing the chat in any case. This setting will take priority
# over both recovery_chat_sync_limit and initial_chat_sync_count.
# Default is 3 days = 259200 seconds
sync_max_chat_age: 259200
# Whether or not to sync with custom puppets to receive EDUs that
# are not normally sent to appservices.
sync_with_custom_puppets: true sync_with_custom_puppets: true
# Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth # 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
# 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
# Servers to always allow double puppeting from
double_puppet_server_map:
"{{ matrix_mautrix_whatsapp_homeserver_domain }}": {{ matrix_mautrix_whatsapp_homeserver_address }}
# 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, custom puppets will be enabled automatically for local users # If set, double puppeting will be enabled automatically for local users
# instead of users having to find an access token and run `login-matrix` # instead of users having to find an access token and run `login-matrix`
# manually. # manually.
login_shared_secret: {{ matrix_mautrix_whatsapp_login_shared_secret|to_json }} login_shared_secret_map: {{ matrix_mautrix_whatsapp_bridge_login_shared_secret_map|to_json }}
# Should the bridge explicitly set the avatar and room name for private chat portal rooms?
# Whether or not to invite own WhatsApp user's Matrix puppet into private
# chat portals when backfilling if needed.
# This always uses the default puppet instead of custom puppets due to
# rate limits and timestamp massaging.
invite_own_puppet_for_backfilling: true
# Whether or not to explicitly set the avatar and room name for private
# chat portal rooms. This can be useful if the previous field works fine,
# but causes room avatar/name bugs.
private_chat_portal_meta: false 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 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
# 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 # Allow invite permission for user. User can invite any bots to room with whatsapp
# users (private chat and groups) # users (private chat and groups)
allow_user_invite: false 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
# The prefix for commands. Only required in non-management rooms. # The prefix for commands. Only required in non-management rooms.
command_prefix: "!wa" 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: ""
# 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: false
# 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: false
# Options for automatic key sharing.
key_sharing:
# 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: false
# Require the requesting device to have a valid cross-signing signature?
# This doesn't require that the bridge has verified the device, only that the user has verified it.
# Not yet implemented.
require_cross_signing: false
# Require devices to be verified by the bridge?
# Verification by the bridge is not yet implemented.
require_verification: true
# Permissions for using the bridge. # Permissions for using the bridge.
# Permitted values: # Permitted values:
# relay - Talk through the relaybot (if enabled), no access otherwise
# user - Access to use the bridge to chat with a WhatsApp account. # user - Access to use the bridge to chat with a WhatsApp account.
# admin - User level and some additional administration tools # admin - User level and some additional administration tools
# Permitted keys: # Permitted keys:
@ -133,15 +188,13 @@ bridge:
permissions: permissions:
"{{ matrix_mautrix_whatsapp_homeserver_domain }}": user "{{ matrix_mautrix_whatsapp_homeserver_domain }}": user
relaybot: # Settings for relay mode
# Whether or not relaybot support is enabled. 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 enabled: false
# The management room for the bot. This is where all status notifications are posted and # Should only admins be allowed to set themselves as relay users?
# in this room, you can use `!wa <command>` instead of `!wa relaybot <command>`. Omitting admin_only: true
# the command prefix completely like in user management rooms is not possible.
management: '!foo:example.com'
# List of users to invite to all created rooms that include the relaybot.
invites: []
# The formats to use when sending messages to WhatsApp via the relaybot. # The formats to use when sending messages to WhatsApp via the relaybot.
message_formats: message_formats:
m.text: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: {{ '{{ .Message }}' }}" m.text: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: {{ '{{ .Message }}' }}"
@ -152,6 +205,7 @@ bridge:
m.audio: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent an audio file" m.audio: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent an audio file"
m.video: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent a video" m.video: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent a video"
m.location: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent a location" m.location: "<b>{{ '{{ .Sender.Displayname }}' }}</b>: sent a location"
# Logging config. # Logging config.
logging: logging:
# The directory for log files. Will be created if not found. # The directory for log files. Will be created if not found.