diff --git a/rootfs/etc/confd/templates/config.yaml.tmpl b/rootfs/etc/confd/templates/config.yaml.tmpl index 9e47a93..875f4b7 100644 --- a/rootfs/etc/confd/templates/config.yaml.tmpl +++ b/rootfs/etc/confd/templates/config.yaml.tmpl @@ -39,20 +39,6 @@ appservice: 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. @@ -108,6 +94,10 @@ bridge: 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 + # Whether the bridge should send the message status as a custom com.beeper.message_send_status event. + message_status_events: false + # Whether the bridge should send error notices via m.notice events when a message fails to bridge. + message_error_notices: true # 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? @@ -117,24 +107,82 @@ bridge: # 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: - # 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 - # 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. - 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 + # 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. + 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 + # 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. + # These settings determine if the media requests should be done + # automatically during or after backfill. + media_requests: + # Should expired media be automatically requested from the server as + # part of the backfill process? + auto_request_media: true + # Whether to request the media immediately after the media message + # is backfilled ("immediate") or at a specific time of the day + # ("local_time"). + request_method: immediate + # 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 + # 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 # 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? @@ -145,6 +193,11 @@ bridge: # 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 + # Should the bridge use MSC2867 to bridge manual "mark as unread"s from + # WhatsApp and set the unread status on initial backfill? + # This will only work on clients that support the m.marked_unread or + # com.famedly.marked_unread room account data. + sync_manual_marked_unread: true # 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. @@ -192,9 +245,14 @@ bridge: # 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 sending WhatsApp status messages be allowed? + # This can cause issues if the user has lots of contacts, so it's disabled by default. + disable_status_broadcast_send: 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 + # Tag to apply to the status broadcast room. + status_broadcast_tag: m.lowpriority # Should the bridge use thumbnails from WhatsApp? # They're disabled by default due to very low resolution. whatsapp_thumbnail: false @@ -215,6 +273,19 @@ bridge: # 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 + # 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 + # 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: + # Send an error message after this timeout, but keep waiting for the response until the deadline. + # This is counted from the origin_server_ts, so the warning time is consistent regardless of the source of delay. + # If the message is older than this when it reaches the bridge, the message won't be handled at all. + error_after: null + # Drop messages after this timeout. They may still go through if the message got sent to the servers. + # This is counted from the time the bridge starts handling the message. + deadline: 120s # The prefix for commands. Only required in non-management rooms. command_prefix: "!wa" @@ -242,18 +313,53 @@ bridge: # 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: true - # 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: true - # 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 + # Require encryption, drop any unencrypted messages. + require: false + # 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 + # What level of device verification should be required from users? + # + # Valid levels: + # unverified - Send keys to all device in the room. + # cross-signed-untrusted - Require valid cross-signing, but trust all cross-signing keys. + # cross-signed-tofu - Require valid cross-signing, trust cross-signing keys on first use (and reject changes). + # cross-signed-verified - Require valid cross-signing, plus a valid user signature from the bridge bot. + # Note that creating user signatures from the bridge bot is not currently possible. + # verified - Require manual per-device verification + # (currently only possible by modifying the `trust` column in the `crypto_device` database table). + verification_levels: + # Minimum level for which the bridge should send keys to when bridging messages from WhatsApp to Matrix. + receive: unverified + # Minimum level that the bridge should accept for incoming Matrix messages. + send: unverified + # Minimum level that the bridge should require for accepting key requests. + share: cross-signed-tofu + # Options for Megolm room key rotation. These options allow you to + # configure the m.room.encryption event content. See: + # https://spec.matrix.org/v1.3/client-server-api/#mroomencryption for + # more information about that event. + rotation: + # Enable custom Megolm room key rotation settings. Note that these + # settings will only apply to rooms created after this option is + # set. + enable_custom: false + # The maximum number of milliseconds a session should be used + # before changing it. The Matrix spec recommends 604800000 (a week) + # as the default. + milliseconds: 604800000 + # The maximum number of messages that should be sent with a given a + # session before changing it. The Matrix spec recommends 100 as the + # default. + messages: 100 + + # 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 # Permissions for using the bridge. # Permitted values: