Update mautrix whatsapp 0.5.0 -> 0.6.0

roles/matrix-bridge-mautrix-whatsapp/defaults/main.yml

@@ -8,7 +8,7 @@ matrix_mautrix_whatsapp_container_image_self_build: false
 matrix_mautrix_whatsapp_container_image_self_build_repo: "https://mau.dev/mautrix/whatsapp.git"
 matrix_mautrix_whatsapp_container_image_self_build_branch: "{{ 'master' if matrix_mautrix_whatsapp_version == 'latest' else matrix_mautrix_whatsapp_version }}"
 
-matrix_mautrix_whatsapp_version: v0.5.0
+matrix_mautrix_whatsapp_version: v0.6.0
 # See: https://mau.dev/mautrix/whatsapp/container_registry
 matrix_mautrix_whatsapp_docker_image: "{{ matrix_mautrix_whatsapp_docker_image_name_prefix }}mautrix/whatsapp:{{ matrix_mautrix_whatsapp_version }}"
 matrix_mautrix_whatsapp_docker_image_name_prefix: "{{ 'localhost/' if matrix_mautrix_whatsapp_container_image_self_build else 'dock.mau.dev/' }}"

roles/matrix-bridge-mautrix-whatsapp/templates/config.yaml.j2

@@ -5,13 +5,17 @@ homeserver:
     address: {{ matrix_mautrix_whatsapp_homeserver_address }}
     # The domain of the homeserver (for MXIDs, etc).
     domain: {{ matrix_mautrix_whatsapp_homeserver_domain }}
-# Application service host/registration related details.
-# 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
+    # 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: {{ matrix_mautrix_whatsapp_appservice_address }}
@@ -24,11 +28,16 @@ appservice:
         type: {{ matrix_mautrix_whatsapp_appservice_database_type|to_json }}
         # The database URI.
         #   SQLite: File name is enough. https://github.com/mattn/go-sqlite3#connection-string
-        #   Postgres: Connection string. For example, postgres://user:password@host/database
+        #   Postgres: Connection string. For example, postgres://user:password@host/database?sslmode=disable
+        #             To connect via Unix socket, use something like postgres:///dbname?host=/var/run/postgresql
         uri: {{ matrix_mautrix_whatsapp_appservice_database_uri|to_json }}
         # Maximum number of connections. Mostly relevant for Postgres.
         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.
@@ -39,37 +48,71 @@ appservice:
         # 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
+
     # 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?
+    enabled: false
+    # IP and port where the metrics listener should be. The path is always /metrics
+    listen: 127.0.0.1:8001
+
+# Config for things that are directly sent to WhatsApp.
+whatsapp:
+    # Device name that's shown in the "WhatsApp Web" section in the mobile app.
+    os_name: Mautrix-WhatsApp bridge
+    # Browser name that determines the logo shown in the mobile app.
+    # Must be "unknown" for a generic icon or a valid browser name if you want a specific icon.
+    # List of valid browser names: https://github.com/tulir/whatsmeow/blob/8b34d886d543b72e5f4699cf5b2797f68d598f78/binary/proto/def.proto#L38-L51
+    browser_name: unknown
+
 # Bridge config
 bridge:
     # 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_{{.}}' }}"
-    displayname_template: "{{ '{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)' }}"
+    # 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 .BusinessName}}{{.BusinessName}}{{else if .PushName}}{{.PushName}}{{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
-    # Should a "reactions not yet supported" warning be sent to the Matrix room when a user reacts to a message?
-    reaction_notices: true
     portal_message_buffer: 128
-    # Settings for handling history sync payloads. These settings only apply right after login,
+    # Settings for handling history sync payloads.
-    # 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
-        # Maximum age of chats in seconds to create portals for. Set to 0 to create portals for all chats in sync payload.
-        max_age: 604800
         # 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 as of Synapse 1.46, there are still some bugs with the implementation, especially if using event persistence workers.
+        # 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
@@ -80,6 +123,67 @@ bridge:
         # 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
@@ -89,11 +193,26 @@ bridge:
     # 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:
         "{{ matrix_mautrix_whatsapp_homeserver_domain }}": {{ matrix_mautrix_whatsapp_homeserver_address }}
@@ -125,9 +244,14 @@ bridge:
     # 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.
+    # This is only applied when creating the room, the user can unmute 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
@@ -137,6 +261,30 @@ 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
+    # 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: "{{ matrix_mautrix_whatsapp_command_prefix }}"
@@ -163,18 +311,53 @@ bridge:
         # 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: {{ matrix_mautrix_whatsapp_bridge_encryption_default|to_json }}
-        # Options for automatic key sharing.
+        # Require encryption, drop any unencrypted messages.
-        key_sharing:
+        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: {{ matrix_mautrix_whatsapp_bridge_encryption_key_sharing_allow|to_json }}
+        allow_key_sharing: {{ matrix_mautrix_whatsapp_bridge_encryption_key_sharing_allow|to_json }}
-            # Require the requesting device to have a valid cross-signing signature?
+                # What level of device verification should be required from users?
-            # This doesn't require that the bridge has verified the device, only that the user has verified it.
+        #
-            # Not yet implemented.
+        # Valid levels:
-            require_cross_signing: false
+        #   unverified - Send keys to all device in the room.
-            # Require devices to be verified by the bridge?
+        #   cross-signed-untrusted - Require valid cross-signing, but trust all cross-signing keys.
-            # Verification by the bridge is not yet implemented.
+        #   cross-signed-tofu - Require valid cross-signing, trust cross-signing keys on first use (and reject changes).
-            require_verification: true
+        #   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
 
     # Permissions for using the bridge.
     # Permitted values:
@@ -214,14 +397,14 @@ logging:
     # The directory for log files. Will be created if not found.
     directory: ./logs
     # Available variables: .Date for the file date and .Index for different log files on the same day.
-    # empy/null = journal logging only
+    # Set this to null to disable logging to file.
-    file_name_format:
+    file_name_format: null
     # Date format for file names in the Go time format: https://golang.org/pkg/time/#pkg-constants
     file_date_format: "2006-01-02"
     # Log file permissions.
-    file_mode: 0600
+    file_mode: 0o600
     # Timestamp format for log entries in the Go time format.
     timestamp_format: "Jan _2, 2006 15:04:05"
-    # Minimum severity for log messages.
+    # Minimum severity for log messages printed to stdout/stderr. This doesn't affect the log file.
     # Options: debug, info, warn, error, fatal
     print_level: {{ matrix_mautrix_whatsapp_logging_level }}