mautrix-telegram/example-config.yaml

# Homeserver details.
homeserver:
    # The address that this appservice can use to connect to the homeserver.
    address: https://matrix.example.com
    # The domain of the homeserver (also known as server_name, used for MXIDs, etc).
    domain: example.com

    # What software is the homeserver running?
    # Standard Matrix homeservers like Synapse, Dendrite and Conduit should just use "standard" here.
    software: standard
    # The URL to push real-time bridge status to.
    # If set, the bridge will make POST requests to this URL whenever a user's Telegram 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

    # Should the bridge use a websocket for connecting to the homeserver?
    # The server side is currently not documented anywhere and is only implemented by mautrix-wsproxy,
    # mautrix-asmux (deprecated), and hungryserv (proprietary).
    websocket: false
    # How often should the websocket be pinged? Pinging will be disabled if this is zero.
    ping_interval_seconds: 0

# 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:29317

    # The hostname and port where this appservice should listen.
    hostname: 0.0.0.0
    port: 29317

    # The unique ID of this appservice
    id: telegram

    # Appservice bot details.
    bot:
        # Username of the appservice bot.
        username: telegrambot
        # Display name and avatar for bot.
        # Set to "remove" to remove display name/avatar, leave empty to leave display name/avatar as-is.
        displayname: Telegram bridge bot
        avatar: mxc://maunium.net/tJCRmUyJDsgRNgqhOgoiHWbX

    # 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"

    # Whether or not to receive ephemeral events via appservice transactions.
    # Requires MSC2409 support (i.e. Synapse 1.22+).
    ephemeral_events: true

    # Should incoming events be handled asynchronously?
    # This may be necessary for large public instances with lots of messages going through.
    # However, messages will not be guaranteed to be bridged in the same order they were sent in.
    async_transactions: false

    # Localpart template of MXIDs for Telegram users
    # {{.}} is replaced with the internal ID of the Telegram user
    username_template: telegram_{{.}}

# Database config.
database:
    # The database type. "sqlite3-fk-wal" and "postgres" are supported.
    type: sqlite3-fk-wal
    # The database URI.
    #   SQLite: A raw file path is supported, but `file:<path>?_txlock=immediate` is recommended.
    #           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: file:telegramgo.db?_txlock=immediate
    # 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

# Bridge config
bridge:
    message_status_events: true
    delivery_receipts: true
    message_error_notices: true
    sync_direct_chat_list: false
    federate_rooms: false

# Provisioning API configuration
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
    # Enable debug API at /debug with provisioning authentication.
    debug_endpoints: false

    # Provisioning API part of the web server for automated portal creation and fetching information.
    # Used by things like mautrix-manager (https://github.com/tulir/mautrix-manager).
    provisioning:
        # Whether or not the provisioning API should be enabled.
        enabled: true
        # The prefix to use in the provisioning API endpoints.
        prefix: /_matrix/provision
        # The shared secret to authorize users of the API.
        # Set to "generate" to generate and save a new token.
        shared_secret: generate

# Double-puppet configuration
double_puppet:
    # Servers to always allow double puppeting from
    servers:
        example.com: https://example.com
    # Allow using double puppeting from any server with a valid client .well-known file.
    allow_discovery: false
    # Per-server 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.
    secrets:
        example.com: foobar

# 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.
    default: false
    # Whether to use MSC2409/MSC3202 instead of /sync long polling for receiving encryption-related data.
    appservice: false
    # Require encryption, drop any unencrypted messages.
    require: false

    # Enable plaintext mentions?
    plaintext_mentions: true

    # Pickle key
    pickle_key: null

    # 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
    # Options for deleting megolm sessions from the bridge.
    delete_keys:
        # Beeper-specific: delete outbound sessions when hungryserv confirms
        # that the user has uploaded the key to key backup.
        delete_outbound_on_ack: false
        # Don't store outbound sessions in the inbound table.
        dont_store_outbound: false
        # Ratchet megolm sessions forward after decrypting messages.
        ratchet_on_decrypt: false
        # Delete fully used keys (index >= max_messages) after decrypting messages.
        delete_fully_used_on_decrypt: false
        # Delete previous megolm sessions from same device when receiving a new one.
        delete_prev_on_new_session: false
        # Delete megolm sessions received from a device when the device is deleted.
        delete_on_device_delete: false
        # Periodically delete megolm sessions when 2x max_age has passed since receiving the session.
        periodically_delete_expired: false
        # Delete inbound megolm sessions that don't have the received_at field used for
        # automatic ratcheting and expired session deletion. This is meant as a migration
        # to delete old keys prior to the bridge update.
        delete_outdated_inbound: 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 Telegram 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

        # Disable rotating keys when a user's devices change?
        # You should not enable this option unless you understand all the implications.
        disable_device_change_key_rotation: false

# Permissions for using the bridge.
# Permitted values:
#   relaybot - Only use the bridge via the relaybot, no access to commands.
#       user - Relaybot level + access to commands to create bridges.
#  puppeting - User level + logging in with a Telegram account.
#       full - Full access to use the bridge, i.e. previous levels + Matrix login.
#      admin - Full access to use the bridge and some extra administration commands.
# Permitted keys:
#        * - All Matrix users
#   domain - All users on that homeserver
#     mxid - Specific user
permissions:
    "*": "relaybot"
    "public.example.com": "user"
    "example.com": "full"
    "@admin:example.com": "admin"

# Messages sent upon joining a management room.
# Markdown is supported. The defaults are listed below.
management_room_texts:
    # Sent when joining a room.
    welcome: "Hello, I'm a Telegram 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: ""

# Logging config. See https://github.com/tulir/zeroconfig for details.
logging:
    min_level: debug
    writers:
    - type: stdout
      format: pretty-colored
    - type: file
      format: json
      filename: ./logs/mautrix-signal.log
      max_size: 100
      max_backups: 10
      compress: true

# Telegram config
network:
    # Get your own API keys at https://my.telegram.org/apps
    api_id: 12345
    api_hash: tjyd5yge35lbodk1xwzw2jstp90k55qz
    # (Optional) Create your own bot at https://t.me/BotFather
    bot_token: disabled

    # Should the bridge request missed updates from Telegram when restarting?
    catch_up: true
    # Should incoming updates be handled sequentially to make sure order is preserved on Matrix?
    sequential_updates: true
    exit_on_update_error: false

    # Telethon connection options.
    connection:
        # The timeout in seconds to be used when connecting.
        timeout: 120
        # How many times the reconnection should retry, either on the initial connection or when
        # Telegram disconnects us. May be set to a negative or null value for infinite retries, but
        # this is not recommended, since the program can get stuck in an infinite loop.
        retries: 5
        # The delay in seconds to sleep between automatic reconnections.
        retry_delay: 1
        # The threshold below which the library should automatically sleep on flood wait errors
        # (inclusive). For instance, if a FloodWaitError for 17s occurs and flood_sleep_threshold
        # is 20s, the library will sleep automatically. If the error was for 21s, it would raise
        # the error instead. Values larger than a day (86400) will be changed to a day.
        flood_sleep_threshold: 60
        # How many times a request should be retried. Request are retried when Telegram is having
        # internal issues, when there is a FloodWaitError less than flood_sleep_threshold, or when
        # there's a migrate error. May take a negative or null value for infinite retries, but this
        # is not recommended, since some requests can always trigger a call fail (such as searching
        # for messages).
        request_retries: 5
        # Use IPv6 for Telethon connection
        use_ipv6: false

    # Device info sent to Telegram.
    device_info:
        # "auto" = OS name+version.
        device_model: mautrix-telegram
        # "auto" = Telethon version.
        system_version: auto
        # "auto" = mautrix-telegram version.
        app_version: auto
        lang_code: en
        system_lang_code: en

    # Custom server to connect to.
    server:
        # Set to true to use these server settings. If false, will automatically
        # use production server assigned by Telegram. Set to false in production.
        enabled: false
        # The DC ID to connect to.
        dc: 2
        # The IP to connect to.
        ip: 149.154.167.40
        # The port to connect to. 443 may not work, 80 is better and both are equally secure.
        port: 80

    # Telethon proxy configuration.
    # You must install PySocks from pip for proxies to work.
    proxy:
        # Allowed types: disabled, socks4, socks5, http, mtproxy
        type: disabled
        # Proxy IP address and port.
        address: 127.0.0.1
        port: 1080
        # Whether or not to perform DNS resolving remotely. Only for socks/http proxies.
        rdns: true
        # Proxy authentication (optional). Put MTProxy secret in password field.
        username: ""
        password: ""