From 4df36357afeb2282606db4ac5f346d9a4c1e3da1 Mon Sep 17 00:00:00 2001 From: Magic_RB Date: Sun, 14 May 2023 14:23:31 +0200 Subject: [PATCH] Update Mautrix Facebook config file Signed-off-by: Magic_RB --- containers/mautrix-facebook.yaml | 124 ++++++++++++++++++++++++------- 1 file changed, 99 insertions(+), 25 deletions(-) diff --git a/containers/mautrix-facebook.yaml b/containers/mautrix-facebook.yaml index 91f9bc6..513d60e 100644 --- a/containers/mautrix-facebook.yaml +++ b/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: - example.com: https://example.com + double_puppet_server_map: {} # 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: - example.com: foobar + login_shared_secret_map: {} # 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 - # invited to private chats when backfilling history from Facebook. This is - # usually needed to prevent rate limits and to allow timestamp massaging. - invite_own_puppet: true - # Maximum number of messages to backfill initially. - # Set to 0 to disable backfilling when creating portal. - initial_limit: 0 - # Maximum number of messages to backfill if messages were missed while - # the bridge was disconnected. - # Set to 0 to disable backfilling missed messages. - missed_limit: 1000 - # If using double puppeting, should notifications be disabled - # while the initial backfill is in progress? - disable_notifications: false + # Allow backfilling at all? + enable: true + # Use MSC2716 for backfilling? If this is disabled, backfilling only happens when syncing threads, + # and the incremental settings below don't apply. + # + # 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. + msc2716: false + # Use double puppets for backfilling? + # + # If using MSC2716, 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). + # + # 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? - sync_on_startup: true + # The maximum number of conversations that should be synced when we get a + # 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: '$sender_displayname: $message' - m.notice: '$sender_displayname: $message' - m.emote: '* $sender_displayname $message' + m.notice: '$sender_displayname: $message' + m.emote: '* $sender_displayname $message' m.file: '$sender_displayname sent a file' m.image: '$sender_displayname sent an image' m.audio: '$sender_displayname sent an audio file'