diff --git a/roles/custom/matrix-bridge-mautrix-whatsapp/templates/config.yaml.j2 b/roles/custom/matrix-bridge-mautrix-whatsapp/templates/config.yaml.j2 index ad381f6aa..80e0f683a 100644 --- a/roles/custom/matrix-bridge-mautrix-whatsapp/templates/config.yaml.j2 +++ b/roles/custom/matrix-bridge-mautrix-whatsapp/templates/config.yaml.j2 @@ -54,16 +54,17 @@ appservice: # 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 + ephemeral_events: true + + # Should incoming events be handled asynchronously? + # This may be necessary for large public instances with lots of messages going through. + # However, messages will not be guaranteed to be bridged in the same order they were sent in. + async_transactions: false # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify. as_token: "{{ matrix_mautrix_whatsapp_appservice_token }}" hs_token: "{{ matrix_mautrix_whatsapp_homeserver_token }}" -# Segment API key to track some events, like provisioning API login and encryption errors. -segment_key: null - # Prometheus config. metrics: # Enable prometheus metrics? @@ -92,7 +93,7 @@ bridge: # 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 .BusinessName}}{{.BusinessName}}{{else if .PushName}}{{.PushName}}{{else}}{{.JID}}{{end}} (WA)' }}" + displayname_template: "{{ '{{or .BusinessName .PushName .JID}} (WhatsApp)' }}" # 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: {{ matrix_mautrix_whatsapp_bridge_personal_filtering_spaces | to_json }} @@ -109,23 +110,38 @@ bridge: portal_message_buffer: 128 # Settings for handling history sync payloads. 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. - # Doesn't work out of box with this playbook - double_puppet_backfill: false + # Enable backfilling history sync payloads from WhatsApp? + backfill: true + # The maximum number of initial conversations that should be synced. + # Other conversations will be backfilled on demand when receiving a message or when initiating a direct chat. + max_initial_conversations: -1 + # Maximum number of messages to backfill in each conversation. + # Set to -1 to disable limit. + message_count: 50 # 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 + # Configuration parameters that are sent to the phone along with the request full sync flag. + # By default (when the values are null or 0), the config isn't sent at all. + full_sync_config: + # Number of days of history to request. + # The limit seems to be around 3 years, but using higher values doesn't break. + days_limit: null + # This is presumably the maximum size of the transferred history sync blob, which may affect what the phone includes in the blob. + size_mb_limit: null + # This is presumably the local storage quota, which may affect what the phone includes in the history sync blob. + storage_quota_mb: null + # If this value is greater than 0, then if the conversation's last message was more than + # this number of hours ago, then the conversation will automatically be marked it as read. + # Conversations that have a last message that is less than this number of hours ago will + # have their unread status synced from WhatsApp. + unread_hours_threshold: 0 + + ############################################################################### + # The settings below are only applicable for backfilling using batch sending, # + # which is no longer supported in Synapse. # + ############################################################################### + # 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. @@ -142,17 +158,6 @@ bridge: # 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 - # If this value is greater than 0, then if the conversation's last - # message was more than this number of hours ago, then the conversation - # will automatically be marked it as read. - # Conversations that have a last message that is less than this number - # of hours ago will have their unread status synced from WhatsApp. - unread_hours_threshold: 0 # 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 @@ -192,12 +197,11 @@ bridge: - 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. @@ -210,7 +214,6 @@ bridge: # 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 @@ -235,7 +238,7 @@ bridge: 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? # This is implicitly enabled in encrypted rooms. - private_chat_portal_meta: false + private_chat_portal_meta: default # Should group members be synced in parallel? This makes member sync faster parallel_member_sync: false # Should Matrix m.notice-type messages be bridged? @@ -273,10 +276,6 @@ bridge: # Whether or not created rooms should have federation enabled. # If false, created portal rooms will never be federated. federate_rooms: {{ matrix_mautrix_whatsapp_federate_rooms|to_json }} - # 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 @@ -290,11 +289,15 @@ bridge: # 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 + # Send galleries as a single event? This is not an MSC (yet). + beeper_galleries: false # Should polls be sent using MSC3381 event types? extev_polls: false - # Should Matrix edits be bridged to WhatsApp edits? - # Official WhatsApp clients don't render edits yet, but once they do, the bridge should work with them right away. - send_whatsapp_edits: false + # Should cross-chat replies from WhatsApp be bridged? Most servers and clients don't support this. + cross_room_replies: false + # Disable generating reply fallbacks? Some extremely bad clients still rely on them, + # but they're being phased out and will be completely removed in the future. + disable_reply_fallbacks: 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: @@ -338,7 +341,30 @@ bridge: # 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: {{ matrix_mautrix_whatsapp_bridge_encryption_key_sharing_allow|to_json }} - # What level of device verification should be required from users? + # Should users mentions be in the event wire content to enable the server to send push notifications? + plaintext_mentions: false + # Options for deleting megolm sessions from the bridge. + delete_keys: + # Beeper-specific: delete outbound sessions when hungryserv confirms + # that the user has uploaded the key to key backup. + delete_outbound_on_ack: false + # Don't store outbound sessions in the inbound table. + dont_store_outbound: false + # Ratchet megolm sessions forward after decrypting messages. + ratchet_on_decrypt: false + # Delete fully used keys (index >= max_messages) after decrypting messages. + delete_fully_used_on_decrypt: false + # Delete previous megolm sessions from same device when receiving a new one. + delete_prev_on_new_session: false + # Delete megolm sessions received from a device when the device is deleted. + delete_on_device_delete: false + # Periodically delete megolm sessions when 2x max_age has passed since receiving the session. + periodically_delete_expired: false + # Delete inbound megolm sessions that don't have the received_at field used for + # automatic ratcheting and expired session deletion. This is meant as a migration + # to delete old keys prior to the bridge update. + delete_outdated_inbound: false + # What level of device verification should be required from users? # # Valid levels: # unverified - Send keys to all device in the room. @@ -373,6 +399,10 @@ bridge: # default. messages: 100 + # Disable rotating keys when a user's devices change? + # You should not enable this option unless you understand all the implications. + disable_device_change_key_rotation: false + # Settings for provisioning API provisioning: # Prefix for the provisioning API paths.