Merge branch 'testing' into packaging-v2

.github/workflows/updater.sh

@@ -148,7 +148,7 @@ yq -i '.bridge.encryption.require = "__ENCRYPTION_REQUIRE__"' $configFilePath
 yq -i 'with(.bridge.permissions ; . = { "__LISTRELAY__": "relay", "__LISTUSER__": "user", "__LISTADMIN__": "admin" } | ... style="double")' $configFilePath
 yq -i '.bridge.relay.enabled = "__ENABLE_RELAYBOT__"' $configFilePath
 yq -i '.bridge.relay.admin_only = "__ADMIN_ONLY__"' $configFilePath
-yq -i '.logging.writers.filename = "/var/log/__APP__"' $configFilePath
+yq -i '.logging.writers.filename = "/var/log/__APP__/__APP__.log"' $configFilePath
 yq -i '.logging.min_level = "__PRINT_LEVEL__"' $configFilePath
 
 #=================================================

README.md

@@ -25,7 +25,7 @@ Therefore, [Synapse for YunoHost](https://github.com/YunoHost-Apps/synapse_ynh)
 ** Attention: always backup and restore the Yunohost matrix_synapse et mautrix_whatsapp apps together!**
 
 
-**Shipped version:** 0.8.5~ynh1
+**Shipped version:** 0.9.0~ynh1
 ## Disclaimers / important information
 
 ## List of known public services

README_fr.md

@@ -25,7 +25,7 @@ C'est pourquoi [Synapse for YunoHost](https://github.com/YunoHost-Apps/synapse_y
 ** Attention : sauvegardez et restaurez toujours les deux applications Yunohost matrix_synapse et mautrix_whatsapp en même temps!**
 
 
-**Version incluse :** 0.8.5~ynh1
+**Version incluse :** 0.9.0~ynh1
 ## Avertissements / informations importantes
 
 ## Liste de passerelles publiques

conf/config.yaml

@@ -15,6 +15,12 @@ homeserver:
   message_send_checkpoint_endpoint: null
   # Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246?
   async_media: __ASYNC_MEDIA__
+  # Should the bridge use a websocket for connecting to the homeserver?
+  # The server side is currently not documented anywhere and is only implemented by mautrix-wsproxy,
+  # mautrix-asmux (deprecated), and hungryserv (proprietary).
+  websocket: false
+  # How often should the websocket be pinged? Pinging will be disabled if this is zero.
+  ping_interval_seconds: 0
 # Application service host/registration related details.
 # Changing these values requires regeneration of the registration.
 appservice:
@@ -77,7 +83,7 @@ whatsapp:
   os_name: __OS_NAME__
   # 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
+  # List of valid browser names: https://github.com/tulir/whatsmeow/blob/efc632c008604016ddde63bfcfca8de4e5304da9/binary/proto/def.proto#L43-L64
   browser_name: __BROWSER_NAME__
 # Bridge config
 bridge:
@@ -91,7 +97,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}} (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: __PERSONAL_FILTERING_SPACES__
@@ -108,20 +114,14 @@ bridge:
   portal_message_buffer: 128
   # Settings for handling history sync payloads.
   history_sync:
-    # Enable backfilling history sync payloads from WhatsApp using batch sending?
+    # Enable backfilling history sync payloads from WhatsApp?
-    # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
+    backfill: true
-    # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
+    # The maximum number of initial conversations that should be synced.
-    # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
+    # Other conversations will be backfilled on demand when receiving a message or when initiating a direct chat.
-    # There are also still some issues in Synapse's federation implementation.
+    max_initial_conversations: -1
-    backfill: false
+    # Maximum number of messages to backfill in each conversation.
-    # Should the bridge create portals for chats in the history sync payload?
+    # Set to -1 to disable limit.
-    # This has no effect unless backfill is enabled.
+    message_count: 50
-    create_portals: true
-    # 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
@@ -135,51 +135,42 @@ bridge:
       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
-    # Settings for media requests. If the media expired, then it will not
+    # If this value is greater than 0, then if the conversation's last message was more than
-    # be on the WA servers.
+    # this number of hours ago, then the conversation will automatically be marked it as read.
-    # Media can always be requested by reacting with the ♻️ (recycle) emoji.
+    # Conversations that have a last message that is less than this number of hours ago will
-    # These settings determine if the media requests should be done
+    # have their unread status synced from WhatsApp.
-    # 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
-    # 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
+    # The settings below are only applicable for backfilling using batch sending, #
-    # (as configured by max_initial_conversations) with a few messages so
+    # which is no longer supported in Synapse.                                    #
-    # that you can continue conversations without loosing context.
+    ###############################################################################
+
+    # 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
+    # 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 losing context.
     immediate:
-      # The number of concurrent backfill workers to create for immediate
+      # The number of concurrent backfill workers to create for immediate backfills.
-      # backfills. Note that using more than one worker could cause the
+      # Note that using more than one worker could cause the room list to jump around
-      # room list to jump around since there are no guarantees about the
+      # since there are no guarantees about the order in which the backfills will complete.
-      # 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
+    # Settings for deferred backfills. The purpose of these backfills are to fill in the rest of
-    # to fill in the rest of the chat history that was not covered by the
+    # the chat history that was not covered by the immediate backfills.
-    # immediate backfills. These backfills generally should happen at a
+    # These backfills generally should happen at a slower pace so as not to overload the homeserver.
-    # 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).
-    # Each deferred backfill config should define a "stage" of backfill
+    # The fields are as follows:
-    # (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.
@@ -363,6 +354,10 @@ bridge:
       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:
@@ -397,6 +392,9 @@ bridge:
       # session before changing it. The Matrix spec recommends 100 as the
       # 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.
@@ -414,9 +412,9 @@ bridge:
   #   domain - All users on that homeserver
   #     mxid - Specific user
   permissions:
-    "__LISTRELAY__": relay
+    "__LISTRELAY__": "relay"
-    "__LISTUSER__": user
+    "__LISTUSER__": "user"
-    "__LISTADMIN__": admin
+    "__LISTADMIN__": "admin"
   # Settings for relay mode
   relay:
     # Whether relay mode should be allowed. If allowed, `!wa set-relay` can be used to turn any