Matrix-synapse-shared-secret-auth Alternatives

matrix-synapse-shared-secret-auth reviews and mentions

• Mautrix-whatsapp configuration
  3 projects | reddit.com/r/matrixdotorg | 13 May 2022

  bridge:    # Localpart template of MXIDs for WhatsApp users.    # {{.}} is replaced with the phone number of the WhatsApp user.    usernametemplate: 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        # 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?    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 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    # 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