mirror of
https://github.com/tulir/mautrix-whatsapp
synced 2024-05-31 18:18:57 +02:00
f2e762680c
This adds a new backfill type for media that sends a request to the phone for every media that is not available on the WA servers. WA deletes media from their servers after about two weeks, so you have to ask the phone to re-upload it. In order to use this, you need to enable bridge.history_sync.backfill_media and configure the requests that will be made per portal using bridge.history_sync.media (which is similar to the deferred backfill config). If you already have backfilled portals, but want to do a one-off media backfill for all existing portals, you can set bridge.history_sync.enqueue_backfill_media_next_start to true.
373 lines
19 KiB
YAML
373 lines
19 KiB
YAML
# Homeserver details.
|
|
homeserver:
|
|
# The address that this appservice can use to connect to the homeserver.
|
|
address: https://example.com
|
|
# The domain of the homeserver (for MXIDs, etc).
|
|
domain: example.com
|
|
|
|
# Is the homeserver actually mautrix-asmux?
|
|
asmux: false
|
|
# The URL to push real-time bridge status to.
|
|
# If set, the bridge will make POST requests to this URL whenever a user's whatsapp connection state changes.
|
|
# The bridge will use the appservice as_token to authorize requests.
|
|
status_endpoint: null
|
|
# Endpoint for reporting per-message status.
|
|
message_send_checkpoint_endpoint: null
|
|
# Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246?
|
|
async_media: false
|
|
|
|
# Application service host/registration related details.
|
|
# Changing these values requires regeneration of the registration.
|
|
appservice:
|
|
# The address that the homeserver can use to connect to this appservice.
|
|
address: http://localhost:29318
|
|
|
|
# The hostname and port where this appservice should listen.
|
|
hostname: 0.0.0.0
|
|
port: 29318
|
|
|
|
# Database config.
|
|
database:
|
|
# The database type. "sqlite3" and "postgres" are supported.
|
|
type: sqlite3
|
|
# The database URI.
|
|
# SQLite: File name is enough. https://github.com/mattn/go-sqlite3#connection-string
|
|
# Postgres: Connection string. For example, postgres://user:password@host/database?sslmode=disable
|
|
# To connect via Unix socket, use something like postgres:///dbname?host=/var/run/postgresql
|
|
uri: mautrix-whatsapp.db
|
|
# Maximum number of connections. Mostly relevant for Postgres.
|
|
max_open_conns: 20
|
|
max_idle_conns: 2
|
|
# Maximum connection idle time and lifetime before they're closed. Disabled if null.
|
|
# Parsed with https://pkg.go.dev/time#ParseDuration
|
|
max_conn_idle_time: null
|
|
max_conn_lifetime: null
|
|
|
|
# Settings for provisioning API
|
|
provisioning:
|
|
# Prefix for the provisioning API paths.
|
|
prefix: /_matrix/provision
|
|
# Shared secret for authentication. If set to "generate", a random secret will be generated,
|
|
# or if set to "disable", the provisioning API will be disabled.
|
|
shared_secret: generate
|
|
# Segment API key to enable analytics tracking for web server
|
|
# endpoints. Set to null to disable.
|
|
# Currently the only events are login start, QR code retrieve, and login
|
|
# success/failure.
|
|
segment_key: null
|
|
|
|
# The unique ID of this appservice.
|
|
id: whatsapp
|
|
# Appservice bot details.
|
|
bot:
|
|
# Username of the appservice bot.
|
|
username: whatsappbot
|
|
# Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
|
|
# to leave display name/avatar as-is.
|
|
displayname: WhatsApp bridge bot
|
|
avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr
|
|
|
|
# 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
|
|
|
|
# Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
|
|
as_token: "This value is generated when generating the registration"
|
|
hs_token: "This value is generated when generating the registration"
|
|
|
|
# Prometheus config.
|
|
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
|
|
|
|
# Config for things that are directly sent to WhatsApp.
|
|
whatsapp:
|
|
# Device name that's shown in the "WhatsApp Web" section in the mobile app.
|
|
os_name: Mautrix-WhatsApp bridge
|
|
# Browser name that determines the logo shown in the mobile app.
|
|
# Must be "unknown" for a generic icon or a valid browser name if you want a specific icon.
|
|
# List of valid browser names: https://github.com/tulir/whatsmeow/blob/2a72655ef600a7fd7a2e98d53ec6da029759c4b8/binary/proto/def.proto#L1582-L1594
|
|
browser_name: unknown
|
|
|
|
# Bridge config
|
|
bridge:
|
|
# Localpart template of MXIDs for WhatsApp users.
|
|
# {{.}} is replaced with the phone number of the WhatsApp user.
|
|
username_template: whatsapp_{{.}}
|
|
# Displayname template for WhatsApp users.
|
|
# {{.PushName}} - nickname set by the WhatsApp user
|
|
# {{.BusinessName}} - validated WhatsApp business name
|
|
# {{.Phone}} - phone number (international format)
|
|
# 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 .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"
|
|
# 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: false
|
|
# Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
|
|
delivery_receipts: false
|
|
# Should incoming calls send a message to the Matrix room?
|
|
call_start_notices: true
|
|
# Should another user's cryptographic identity changing send a message to Matrix?
|
|
identity_change_notices: false
|
|
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
|
|
# Enable requesting media that was not found on the WhatsApp server.
|
|
# Only applies if backfill is true.
|
|
backfill_media: false
|
|
# Enqueue backfilling of media that was not found on the WhatsApp
|
|
# server on next startup for all portals.
|
|
# Only applies if backfill and backfill_media are true.
|
|
enqueue_backfill_media_next_start: 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.
|
|
double_puppet_backfill: false
|
|
# 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
|
|
# 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
|
|
# 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
|
|
# that you can continue conversations without loosing context.
|
|
immediate:
|
|
# The number of concurrent backfill workers to create for immediate
|
|
# backfills. Note that using more than one worker could cause the
|
|
# room list to jump around since there are no guarantees about the
|
|
# order in which the backfills will complete.
|
|
worker_count: 1
|
|
# The maximum number of events to backfill initially.
|
|
max_events: 10
|
|
# Settings for deferred backfills. The purpose of these backfills are
|
|
# to fill in the rest of the chat history that was not covered by the
|
|
# immediate backfills. These backfills generally should happen at a
|
|
# slower pace so as not to overload the homeserver.
|
|
# Each deferred backfill config should define a "stage" of backfill
|
|
# (i.e. the last week of messages). The fields are as follows:
|
|
# - start_days_ago: the number of days ago to start backfilling from.
|
|
# To indicate the start of time, use -1. For example, for a week ago, use 7.
|
|
# - max_batch_events: the number of events to send per batch.
|
|
# - batch_delay: the number of seconds to wait before backfilling each batch.
|
|
deferred:
|
|
# Last Week
|
|
- start_days_ago: 7
|
|
max_batch_events: 20
|
|
batch_delay: 5
|
|
# Last Month
|
|
- start_days_ago: 30
|
|
max_batch_events: 50
|
|
batch_delay: 10
|
|
# Last 3 months
|
|
- start_days_ago: 90
|
|
max_batch_events: 100
|
|
batch_delay: 10
|
|
# The start of time
|
|
- start_days_ago: -1
|
|
max_batch_events: 500
|
|
batch_delay: 10
|
|
# Settings for automatically requesting all media that was not found on
|
|
# the WhatsApp server. This process happens after the deferred
|
|
# backfills are completed.
|
|
# The config is the same as for deferred backfills, except the
|
|
# max_batch_events represents the maximum number of media messages to
|
|
# request.
|
|
media:
|
|
# Last Month
|
|
- start_days_ago: 30
|
|
max_batch_events: 5
|
|
batch_delay: 10
|
|
# Last 3 months
|
|
- start_days_ago: 90
|
|
max_batch_events: 5
|
|
batch_delay: 10
|
|
# The start of time
|
|
- start_days_ago: -1
|
|
max_batch_events: 10
|
|
batch_delay: 20
|
|
# 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.
|
|
sync_direct_chat_list: false
|
|
# 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
|
|
# users to see when the whatsapp user on the other side is typing during a conversation.
|
|
send_presence_on_typing: false
|
|
# Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)
|
|
# even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?
|
|
#
|
|
# By default, the bridge acts like WhatsApp web, which only sends active delivery
|
|
# receipts when it's in the foreground.
|
|
force_active_delivery_receipts: false
|
|
# Servers to always allow double puppeting from
|
|
double_puppet_server_map:
|
|
example.com: https://example.com
|
|
# 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
|
|
#
|
|
# 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_map:
|
|
example.com: foobar
|
|
# Should the bridge explicitly set the avatar and room name for private chat portal rooms?
|
|
private_chat_portal_meta: false
|
|
# 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.
|
|
resend_bridge_info: false
|
|
# When using double puppeting, should muted chats be muted in Matrix?
|
|
mute_bridging: false
|
|
# When using double puppeting, should archived chats be moved to a specific tag in Matrix?
|
|
# Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.
|
|
# This can be set to a tag (e.g. m.lowpriority), or null to disable.
|
|
archive_tag: null
|
|
# Same as above, but for pinned chats. The favorite tag is called m.favourite
|
|
pinned_tag: null
|
|
# Should mute status and tags only be bridged when the portal room is created?
|
|
tag_only_on_create: true
|
|
# Should WhatsApp status messages be bridged into a Matrix room?
|
|
# Disabling this won't affect already created status broadcast rooms.
|
|
enable_status_broadcast: true
|
|
# Should the status broadcast room be muted and moved into low priority by default?
|
|
# This is only applied when creating the room, the user can unmute/untag it later.
|
|
mute_status_broadcast: true
|
|
# Should the bridge use thumbnails from WhatsApp?
|
|
# They're disabled by default due to very low resolution.
|
|
whatsapp_thumbnail: false
|
|
# Allow invite permission for user. User can invite any bots to room with whatsapp
|
|
# users (private chat and groups)
|
|
allow_user_invite: false
|
|
# Whether or not created rooms should have federation enabled.
|
|
# If false, created portal rooms will never be federated.
|
|
federate_rooms: true
|
|
# 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
|
|
# Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,
|
|
# and send it to WhatsApp? URL previews can always be sent using the `com.beeper.linkpreviews`
|
|
# key in the event content even if this is disabled.
|
|
url_previews: false
|
|
|
|
# The prefix for commands. Only required in non-management rooms.
|
|
command_prefix: "!wa"
|
|
|
|
# Messages sent upon joining a management room.
|
|
# Markdown is supported. The defaults are listed below.
|
|
management_room_text:
|
|
# Sent when joining a room.
|
|
welcome: "Hello, I'm a WhatsApp bridge bot."
|
|
# Sent when joining a management room and the user is already logged in.
|
|
welcome_connected: "Use `help` for help."
|
|
# Sent when joining a management room and the user is not logged in.
|
|
welcome_unconnected: "Use `help` for help or `login` to log in."
|
|
# Optional extra text sent when joining a management room.
|
|
additional_help: ""
|
|
|
|
# End-to-bridge encryption support options.
|
|
#
|
|
# See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html for more info.
|
|
encryption:
|
|
# Allow encryption, work in group chat rooms with e2ee enabled
|
|
allow: false
|
|
# Default to encryption, force-enable encryption in all portals the bridge creates
|
|
# This will cause the bridge bot to be in private chats for the encryption to work properly.
|
|
# It is recommended to also set private_chat_portal_meta to true when using this.
|
|
default: false
|
|
# Options for automatic key sharing.
|
|
key_sharing:
|
|
# 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: false
|
|
# Require the requesting device to have a valid cross-signing signature?
|
|
# This doesn't require that the bridge has verified the device, only that the user has verified it.
|
|
# Not yet implemented.
|
|
require_cross_signing: false
|
|
# Require devices to be verified by the bridge?
|
|
# Verification by the bridge is not yet implemented.
|
|
require_verification: true
|
|
|
|
# Permissions for using the bridge.
|
|
# Permitted values:
|
|
# relay - Talk through the relaybot (if enabled), no access otherwise
|
|
# user - Access to use the bridge to chat with a WhatsApp account.
|
|
# admin - User level and some additional administration tools
|
|
# Permitted keys:
|
|
# * - All Matrix users
|
|
# domain - All users on that homeserver
|
|
# mxid - Specific user
|
|
permissions:
|
|
"*": relay
|
|
"example.com": user
|
|
"@admin:example.com": admin
|
|
|
|
# Settings for relay mode
|
|
relay:
|
|
# Whether relay mode should be allowed. If allowed, `!wa set-relay` can be used to turn any
|
|
# authenticated user into a relaybot for that chat.
|
|
enabled: false
|
|
# Should only admins be allowed to set themselves as relay users?
|
|
admin_only: true
|
|
# The formats to use when sending messages to WhatsApp via the relaybot.
|
|
message_formats:
|
|
m.text: "<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"
|
|
m.video: "<b>{{ .Sender.Displayname }}</b> sent a video"
|
|
m.location: "<b>{{ .Sender.Displayname }}</b> sent a location"
|
|
|
|
# Logging config.
|
|
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"
|
|
# Log file permissions.
|
|
file_mode: 0o600
|
|
# Timestamp format for log entries in the Go time format.
|
|
timestamp_format: "Jan _2, 2006 15:04:05"
|
|
# 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
|