mirror of
https://git.sr.ht/~magic_rb/cluster
synced 2024-11-24 00:56:16 +01:00
Update Mautrix Facebook config file
Signed-off-by: Magic_RB <magic_rb@redalder.org>
This commit is contained in:
Magic_RB
parent
ecc73b5db2
commit
4df36357af
|
|
@ -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: '<b>$sender_displayname</b>: $message'
|
||||
m.notice: '<b>$sender_displayname<b>: $message'
|
||||
m.emote: '* <b>$sender_displayname<b> $message'
|
||||
m.notice: '<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'
|
||||
|
|
|
|||
Loading…
Reference in a new issue