update configuration file

rootfs/etc/confd/templates/config.yaml.tmpl

@@ -39,20 +39,6 @@ appservice:
     max_conn_idle_time: null
     max_conn_lifetime: null
 
-  
-  # 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
-      # Segment API key to enable analytics tracking for web server
-      # endpoints. Set to null to disable.
-      # Currently the only events are login start, QR code retrieve, and login
-      # success/failure.
-      segment_key: null
-
   # The unique ID of this appservice.
   id: whatsapp
   # Appservice bot details.
@@ -108,6 +94,10 @@ bridge:
   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?
@@ -117,24 +107,82 @@ bridge:
   # 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?
+	# Should the bridge create portals for chats in the history sync payload?
-      create_portals: true
+    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.
+    # Enable backfilling history sync payloads from WhatsApp using batch sending?
-      max_age: 604800
+    # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
-      # Enable backfilling history sync payloads from WhatsApp using batch sending?
+    # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
-      # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
+    # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
-      # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
+    # There are also still some issues in Synapse's federation implementation.
-      # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
+    backfill: false
-      # There are also still some issues in Synapse's federation implementation.
+    # Use double puppets for backfilling?
-      backfill: false
+    # In order to use this, the double puppets must be in the appservice's user ID namespace
-      # Use double puppets for backfilling?
+    # (because the bridge can't use the double puppet access token with batch sending).
-      # In order to use this, the double puppets must be in the appservice's user ID namespace
+    # This only affects double puppets on the local server, double puppets on other servers will never be used.
-      # (because the bridge can't use the double puppet access token with batch sending).
+    double_puppet_backfill: false
-      # This only affects double puppets on the local server, double puppets on other servers will never be used.
+    # Should the bridge request a full sync from the phone when logging in?
-      double_puppet_backfill: false
+    # This bumps the size of history syncs from 3 months to 1 year.
-      # Should the bridge request a full sync from the phone when logging in?
+    request_full_sync: false
-      # This bumps the size of history syncs from 3 months to 1 year.
+    # Settings for media requests. If the media expired, then it will not
-      request_full_sync: false
+    # 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?
@@ -145,6 +193,11 @@ 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.
@@ -192,9 +245,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.
   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
@@ -215,6 +273,19 @@ bridge:
   # 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"
@@ -242,18 +313,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: true
-      # 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.
+      # 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.
+      # You must use a client that supports requesting keys from other users to use this feature.
-          allow: true
+      allow_key_sharing: false
-          # 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: