|
@@ -56,7 +56,7 @@ appservice:
|
|
|
hs_token: "This value is generated when generating the registration"
|
|
|
|
|
|
metrics:
|
|
|
- # Whether or not to enable prometheus metrics
|
|
|
+ # Enable prometheus metrics?
|
|
|
enabled: false
|
|
|
# IP and port where the metrics listener should be. The path is always /metrics
|
|
|
listen: 127.0.0.1:8001
|
|
@@ -83,60 +83,59 @@ bridge:
|
|
|
# {{.FirstName}} - first name from contact list
|
|
|
displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"
|
|
|
|
|
|
- # Whether or not the bridge should send a read receipt from the bridge bot when a message has been
|
|
|
- # sent to WhatsApp. If fetch_message_on_timeout is enabled, a successful post-timeout fetch will
|
|
|
- # trigger a read receipt too.
|
|
|
+ # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
|
|
|
delivery_receipts: false
|
|
|
|
|
|
- portal_message_buffer: 128
|
|
|
-
|
|
|
- # Whether or not to send call start/end notices to Matrix.
|
|
|
+ # Should notices of incoming calls be sent to Matrix?
|
|
|
call_notices:
|
|
|
start: true
|
|
|
end: true
|
|
|
|
|
|
+ # Settings for handling history sync payloads. These settings only apply right after login,
|
|
|
+ # because the phone only sends the history sync data once, and there's no way to re-request it
|
|
|
+ # (other than logging out and back in again).
|
|
|
history_sync:
|
|
|
- # Whether to create portals from history sync payloads from WhatsApp.
|
|
|
+ # Should the bridge create portals for chats in the history sync payload?
|
|
|
create_portals: true
|
|
|
# Maximum age of chats in seconds to create portals for. Set to 0 to create portals for all chats in sync payload.
|
|
|
max_age: 604800
|
|
|
- # Whether to enable backfilling history sync payloads from WhatsApp using batch sending
|
|
|
+ # 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 -> enable_msc2716 to true in homeserver.yaml.
|
|
|
backfill: false
|
|
|
- # Whether to use custom puppet for backfilling.
|
|
|
- # In order to use this, the custom puppets must be in the appservice's user ID namespace.
|
|
|
+ # 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).
|
|
|
double_puppet_backfill: false
|
|
|
- # Whether the client should request a full sync from the phone when logging in.
|
|
|
+ # 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
|
|
|
- # Whether or not puppet avatars should be fetched from the server even if an avatar is already set.
|
|
|
+ # Should puppet avatars be fetched from the server even if an avatar is already set?
|
|
|
user_avatar_sync: true
|
|
|
- # Whether or not Matrix users leaving groups should be bridged to WhatsApp
|
|
|
+ # Should Matrix users leaving groups be bridged to WhatsApp?
|
|
|
bridge_matrix_leave: true
|
|
|
|
|
|
- # Whether or not to sync with custom puppets to receive EDUs that
|
|
|
- # are not normally sent to appservices.
|
|
|
+ # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
|
|
|
sync_with_custom_puppets: true
|
|
|
- # Whether or not to update the m.direct account data event when double puppeting is enabled.
|
|
|
+ # 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.
|
|
|
sync_direct_chat_list: false
|
|
|
- # When double puppeting is enabled, users can use `!wa toggle` to change whether or not
|
|
|
+ # 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
|
|
|
# Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth
|
|
|
#
|
|
|
- # If set, custom puppets will be enabled automatically for local users
|
|
|
+ # If set, double puppeting will be enabled automatically for local users
|
|
|
# instead of users having to find an access token and run `login-matrix`
|
|
|
# manually.
|
|
|
login_shared_secret: null
|
|
|
|
|
|
- # Whether to explicitly set the avatar and room name for private chat portal rooms.
|
|
|
+ # Should the bridge explicitly set the avatar and room name for private chat portal rooms?
|
|
|
private_chat_portal_meta: false
|
|
|
- # Whether Matrix m.notice-type messages should be bridged.
|
|
|
+ # Should Matrix m.notice-type messages be bridged?
|
|
|
bridge_notices: true
|
|
|
# Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
|
|
|
# This field will automatically be changed back to false after it, except if the config file is not writable.
|
|
@@ -149,13 +148,13 @@ bridge:
|
|
|
archive_tag: null
|
|
|
# Same as above, but for pinned chats. The favorite tag is called m.favourite
|
|
|
pinned_tag: null
|
|
|
- # Whether or not mute status and tags should only be bridged when the portal room is created.
|
|
|
+ # Should mute status and tags only be bridged when the portal room is created?
|
|
|
tag_only_on_create: true
|
|
|
- # Whether or not WhatsApp status messages should be bridged into a Matrix room.
|
|
|
+ # Should WhatsApp status messages be bridged into a Matrix room?
|
|
|
# Disabling this won't affect already created status broadcast rooms.
|
|
|
enable_status_broadcast: true
|
|
|
|
|
|
- # Whether or not thumbnails from WhatsApp should be sent.
|
|
|
+ # Should the bridge use thumbnails from WhatsApp?
|
|
|
# They're disabled by default due to very low resolution.
|
|
|
whatsapp_thumbnail: false
|
|
|
|
|
@@ -237,6 +236,7 @@ logging:
|
|
|
# The directory for log files. Will be created if not found.
|
|
|
directory: ./logs
|
|
|
# Available variables: .Date for the file date and .Index for different log files on the same day.
|
|
|
+ # Set this to null to disable logging to file.
|
|
|
file_name_format: "{{.Date}}-{{.Index}}.log"
|
|
|
# Date format for file names in the Go time format: https://golang.org/pkg/time/#pkg-constants
|
|
|
file_date_format: 2006-01-02
|
|
@@ -244,6 +244,6 @@ logging:
|
|
|
file_mode: 0600
|
|
|
# Timestamp format for log entries in the Go time format.
|
|
|
timestamp_format: Jan _2, 2006 15:04:05
|
|
|
- # Minimum severity for log messages.
|
|
|
+ # Minimum severity for log messages printed to stdout/stderr. This doesn't affect the log file.
|
|
|
# Options: debug, info, warn, error, fatal
|
|
|
print_level: debug
|