mirror of
https://github.com/tulir/mautrix-whatsapp
synced 2024-05-29 01:03:53 +02:00
Update comments in example config
This commit is contained in:
parent
d94cd6a669
commit
d19703a02d
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue