Bring config.yaml.j2 in line with upstream (#3163)
* Bring config.yaml.j2 in line with upstream * Update config.yaml.j2
This commit is contained in:
needo37
GitHub
parent
518615a979
commit
8a9a700cfc
@ -54,16 +54,17 @@ appservice:
|
||||
|
||||
# Whether or not to receive ephemeral events via appservice transactions.
|
||||
# Requires MSC2409 support (i.e. Synapse 1.22+).
|
||||
# You should disable bridge -> sync_with_custom_puppets when this is enabled.
|
||||
ephemeral_events: false
|
||||
ephemeral_events: true
|
||||
|
||||
# Should incoming events be handled asynchronously?
|
||||
# This may be necessary for large public instances with lots of messages going through.
|
||||
# However, messages will not be guaranteed to be bridged in the same order they were sent in.
|
||||
async_transactions: false
|
||||
|
||||
# Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
|
||||
as_token: "{{ matrix_mautrix_whatsapp_appservice_token }}"
|
||||
hs_token: "{{ matrix_mautrix_whatsapp_homeserver_token }}"
|
||||
|
||||
# Segment API key to track some events, like provisioning API login and encryption errors.
|
||||
segment_key: null
|
||||
|
||||
# Prometheus config.
|
||||
metrics:
|
||||
# Enable prometheus metrics?
|
||||
@ -92,7 +93,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}} (WhatsApp)' }}"
|
||||
# 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: {{ matrix_mautrix_whatsapp_bridge_personal_filtering_spaces | to_json }}
|
||||
@ -109,23 +110,38 @@ bridge:
|
||||
portal_message_buffer: 128
|
||||
# Settings for handling history sync payloads.
|
||||
history_sync:
|
||||
# Should the bridge create portals for chats in the history sync payload?
|
||||
create_portals: true
|
||||
# Enable backfilling history sync payloads from WhatsApp using batch sending?
|
||||
# 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.
|
||||
# Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
|
||||
# There are also still some issues in Synapse's federation implementation.
|
||||
backfill: false
|
||||
# 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.
|
||||
# Doesn't work out of box with this playbook
|
||||
double_puppet_backfill: false
|
||||
# Enable backfilling history sync payloads from WhatsApp?
|
||||
backfill: true
|
||||
# The maximum number of initial conversations that should be synced.
|
||||
# Other conversations will be backfilled on demand when receiving a message or when initiating a direct chat.
|
||||
max_initial_conversations: -1
|
||||
# Maximum number of messages to backfill in each conversation.
|
||||
# Set to -1 to disable limit.
|
||||
message_count: 50
|
||||
# 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
|
||||
# Configuration parameters that are sent to the phone along with the request full sync flag.
|
||||
# By default (when the values are null or 0), the config isn't sent at all.
|
||||
full_sync_config:
|
||||
# Number of days of history to request.
|
||||
# The limit seems to be around 3 years, but using higher values doesn't break.
|
||||
days_limit: null
|
||||
# This is presumably the maximum size of the transferred history sync blob, which may affect what the phone includes in the blob.
|
||||
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
|
||||
# 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
|
||||
|
||||
###############################################################################
|
||||
# The settings below are only applicable for backfilling using batch sending, #
|
||||
# which is no longer supported in Synapse. #
|
||||
###############################################################################
|
||||
|
||||
# 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.
|
||||
@ -142,17 +158,6 @@ bridge:
|
||||
# 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
|
||||
# (as configured by max_initial_conversations) with a few messages so
|
||||
@ -192,12 +197,11 @@ bridge:
|
||||
- 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?
|
||||
bridge_matrix_leave: true
|
||||
# Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
|
||||
sync_with_custom_puppets: true
|
||||
# Should the bridge update the m.direct account data event when double puppeting is enabled.
|
||||
# Note that updating the m.direct event is not atomic (except with mautrix-asmux)
|
||||
# and is therefore prone to race conditions.
|
||||
@ -210,7 +214,6 @@ bridge:
|
||||
# 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.
|
||||
default_bridge_receipts: true
|
||||
default_bridge_presence: true
|
||||
# Send the presence as "available" to whatsapp when users start typing on a portal.
|
||||
# This works as a workaround for homeservers that do not support presence, and allows
|
||||
@ -235,7 +238,7 @@ bridge:
|
||||
login_shared_secret_map: {{ matrix_mautrix_whatsapp_bridge_login_shared_secret_map|to_json }}
|
||||
# Should the bridge explicitly set the avatar and room name for private chat portal rooms?
|
||||
# This is implicitly enabled in encrypted rooms.
|
||||
private_chat_portal_meta: false
|
||||
private_chat_portal_meta: default
|
||||
# Should group members be synced in parallel? This makes member sync faster
|
||||
parallel_member_sync: false
|
||||
# Should Matrix m.notice-type messages be bridged?
|
||||
@ -273,10 +276,6 @@ bridge:
|
||||
# Whether or not created rooms should have federation enabled.
|
||||
# If false, created portal rooms will never be federated.
|
||||
federate_rooms: {{ matrix_mautrix_whatsapp_federate_rooms|to_json }}
|
||||
# Whether to enable disappearing messages in groups. If enabled, then the expiration time of
|
||||
# the messages will be determined by the first user to read the message, rather than individually.
|
||||
# If the bridge only has a single user, this can be turned on safely.
|
||||
disappearing_messages_in_groups: false
|
||||
# Should the bridge never send alerts to the bridge management room?
|
||||
# These are mostly things like the user being logged out.
|
||||
disable_bridge_alerts: false
|
||||
@ -290,11 +289,15 @@ bridge:
|
||||
# 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
|
||||
# Send galleries as a single event? This is not an MSC (yet).
|
||||
beeper_galleries: false
|
||||
# Should polls be sent using MSC3381 event types?
|
||||
extev_polls: false
|
||||
# Should Matrix edits be bridged to WhatsApp edits?
|
||||
# Official WhatsApp clients don't render edits yet, but once they do, the bridge should work with them right away.
|
||||
send_whatsapp_edits: false
|
||||
# Should cross-chat replies from WhatsApp be bridged? Most servers and clients don't support this.
|
||||
cross_room_replies: false
|
||||
# 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
|
||||
# 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:
|
||||
@ -338,6 +341,29 @@ 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: {{ matrix_mautrix_whatsapp_bridge_encryption_key_sharing_allow|to_json }}
|
||||
# Should users mentions be in the event wire content to enable the server to send push notifications?
|
||||
plaintext_mentions: 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
|
||||
# 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:
|
||||
@ -373,6 +399,10 @@ bridge:
|
||||
# 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.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user