~xenrox/ansible

13318d6ec91fac3b6e9df54b1f9130a81c71cc4a — Thorben Günther 1 year, 9 months ago ca0ed3f
mautrix-whatsapp: Update config

0.4.0 release.
1 files changed, 69 insertions(+), 13 deletions(-)

M roles/matrix/templates/mautrix-whatsapp.yaml.j2
M roles/matrix/templates/mautrix-whatsapp.yaml.j2 => roles/matrix/templates/mautrix-whatsapp.yaml.j2 +69 -13
@@ 50,11 50,6 @@ appservice:
        # 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: {{ matrix_secrets['whatsapp_shared_secret'] }}
        # 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


@@ 76,6 71,9 @@ appservice:
    as_token: "{{ matrix_secrets['whatsapp_as_token'] }}"
    hs_token: "{{ matrix_secrets['whatsapp_hs_token'] }}"

# Segment API key to track some events, like provisioning API login and encryption errors.
segment_key: null

# Prometheus config.
metrics:
    # Enable prometheus metrics?


@@ 89,7 87,7 @@ whatsapp:
    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
    # List of valid browser names: https://github.com/tulir/whatsmeow/blob/8b34d886d543b72e5f4699cf5b2797f68d598f78/binary/proto/def.proto#L38-L51
    browser_name: unknown

# Bridge config


@@ 115,14 113,10 @@ bridge:
    # 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. 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).
    # Settings for handling history sync payloads.
    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.


@@ 137,6 131,66 @@ bridge:
        # 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?


@@ 194,8 248,10 @@ bridge:
    # 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.
    # This is only applied when creating the room, the user can unmute 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


@@ 296,7 352,7 @@ logging:
    # 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: 0600
    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.