Update Mautrix Facebook config file

Signed-off-by: Magic_RB <magic_rb@redalder.org>

containers/mautrix-facebook.yaml

@@ -67,6 +67,8 @@ appservice:
         # Segment API key to enable analytics tracking for web server endpoints. Set to null to disable.
         # Currently the only events are login start, success and fail.
         segment_key: null
+        # Optional user_id to use when sending Segment events. If null, defaults to using mxID.
+        segment_user_id: null
 
     # The unique ID of this appservice.
     id: mufacebook
@@ -125,9 +127,6 @@ bridge:
     # The prefix for commands. Only required in non-management rooms.
     command_prefix: "!fb"
 
-    # Number of chats to sync (and create portals for) on startup/login.
-    # Set 0 to disable automatic syncing.
-    initial_chat_sync: 20
     # Whether or not the Facebook users of logged in Matrix users should be
     # invited to private chats when the user sends a message from another client.
     invite_own_puppet_to_pm: false
@@ -139,8 +138,7 @@ bridge:
     # and is therefore prone to race conditions.
     sync_direct_chat_list: false
     # Servers to always allow double puppeting from
-    double_puppet_server_map:
+    double_puppet_server_map: {}
-        example.com: https://example.com
     # 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
@@ -150,8 +148,7 @@ bridge:
     # manually.
     # If using this for other servers than the bridge's server,
     # you must also set the URL in the double_puppet_server_map.
-    login_shared_secret_map:
+    login_shared_secret_map: {}
-        example.com: foobar
     # Should presence from Facebook be bridged? This doesn't use the same API as the Android app,
     # so it might be more suspicious to Facebook.
     presence_from_facebook: false
@@ -172,20 +169,69 @@ bridge:
     federate_rooms: true
     # Settings for backfilling messages from Facebook.
     backfill:
-        # Whether or not the Facebook users of logged in Matrix users should be
+        # Allow backfilling at all?
-        # invited to private chats when backfilling history from Facebook. This is
+        enable: true
-        # usually needed to prevent rate limits and to allow timestamp massaging.
+        # Use MSC2716 for backfilling? If this is disabled, backfilling only happens when syncing threads,
-        invite_own_puppet: true
+        # and the incremental settings below don't apply.
-        # Maximum number of messages to backfill initially.
+        #
-        # Set to 0 to disable backfilling when creating portal.
+        # This requires a server with MSC2716 support, which is currently an experimental feature in Synapse.
-        initial_limit: 0
+        # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
-        # Maximum number of messages to backfill if messages were missed while
+        msc2716: false
-        # the bridge was disconnected.
+        # Use double puppets for backfilling?
-        # Set to 0 to disable backfilling missed messages.
+        #
-        missed_limit: 1000
+        # If using MSC2716, the double puppets must be in the appservice's user ID namespace
-        # If using double puppeting, should notifications be disabled
+        # (because the bridge can't use the double puppet access token with batch sending).
-        # while the initial backfill is in progress?
+        #
-        disable_notifications: false
+        # Even without MSC2716, bridging old messages with correct timestamps requires the double
+        # puppets to be in an appservice namespace, or the server to be modified to allow
+        # overriding timestamps anyway.
+        double_puppet_backfill: false
+        # The maximum number of 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.
+        # If set to -1, all conversations will by synced.
+        max_conversations: 20
+        # The minimum amount of time to wait between syncing each thread. This
+        # helps avoid situations where you sync too quickly.
+        min_sync_thread_delay: 5
+        # 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 Facebook.
+        unread_hours_threshold: 0
+
+        # Settings for how quickly to backoff when rate-limits are encountered
+        # while backfilling.
+        backoff:
+            # How many seconds to wait after getting rate limited during a
+            # thread list fetch.
+            thread_list: 300
+            # How many seconds to wait after getting rate limited during a
+            # message history fetch.
+            message_history: 300
+
+        # Settings for backfills.
+        #
+        # During initial/incremental sync, the entirety of the thread that is
+        # available will be backfilled. For example, on initial sync, about 20
+        # messages are included for each thread in the thread list returned by
+        # the server. After that, incremental backfills will be run for each of
+        # the portals in a round-robin fashion until all portals have been
+        # backfilled as configured below.
+        incremental:
+            # The maximum number of pages to backfill per batch.
+            max_pages: 10
+            # The maximum number of total pages to backfill per portal.
+            # If set to -1, infinite pages will be synced.
+            max_total_pages: -1
+            # The number of seconds to wait between backfilling each page.
+            page_delay: 5
+            # The number of seconds to wait after backfilling the batch of
+            # messages.
+            post_batch_delay: 20
+
     periodic_reconnect:
         # Interval in seconds in which to automatically reconnect all users.
         # This can be used to automatically mitigate the bug where Facebook stops sending messages.
@@ -202,14 +248,17 @@ bridge:
     # and missed message backfilling when reconnecting.
     # Set to 0 to always re-sync, or -1 to never re-sync automatically.
     resync_max_disconnected_time: 5
-    # Should the bridge do a resync on startup?
+    # The maximum number of conversations that should be synced when we get a
-    sync_on_startup: true
+    # message sync error. In general, 1 page (20) is sufficient.
+    max_startup_thread_sync_count: 20
     # Whether or not temporary disconnections should send notices to the notice room.
     # If this is false, disconnections will never send messages and connections will only send
     # messages if it was disconnected for more than resync_max_disconnected_time seconds.
     temporary_disconnect_notices: false
     # Disable bridge notices entirely
     disable_bridge_notices: false
+    # Should Matrix m.notice-type messages be bridged to Facebook?
+    bridge_matrix_notices: true
     on_reconnection_fail:
         # What to do if a reconnection attempt fails? Options: reconnect, refresh, null
         action: reconnect
@@ -229,6 +278,14 @@ bridge:
     sandbox_media_download: false
     # URL to call to retrieve a proxy URL from (defaults to the http_proxy environment variable).
     get_proxy_api_url: null
+    # Whether to explicitly set the avatar and room name for private chat portal rooms.
+    # If set to `default`, this will be enabled in encrypted rooms and disabled in unencrypted rooms.
+    # If set to `always`, all DM rooms will have explicit names and avatars set.
+    # If set to `never`, DM rooms will never have names and avatars set.
+    private_chat_portal_meta: default
+    # 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
 
     # End-to-bridge encryption support options.
     #
@@ -246,6 +303,23 @@ 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: 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
         # What level of device verification should be required from users?
         #
         # Valid levels:
@@ -308,8 +382,8 @@ bridge:
         #   $message            - The message content
         message_formats:
             m.text: '<b>$sender_displayname</b>: $message'
-            m.notice: '<b>$sender_displayname<b>: $message'
+            m.notice: '<b>$sender_displayname</b>: $message'
-            m.emote: '* <b>$sender_displayname<b> $message'
+            m.emote: '* <b>$sender_displayname</b> $message'
             m.file: '<b>$sender_displayname</b> sent a file'
             m.image: '<b>$sender_displayname</b> sent an image'
             m.audio: '<b>$sender_displayname</b> sent an audio file'