Mautrix-Telegram Bridge (Docker-Compose) auf einer nativen Matrix-Synapse Instanz auf Ubuntu 20.04

Dies soll ein Workaround sein. Alle Angaben natürlich ohne Gewähr. Die Quellen für das Workaround sind

https://docs.mau.fi/bridges/index.html

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-20-04-de

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-compose-on-ubuntu-20-04-de

https://github.com/mautrix/telegram

https://core.telegram.org/api/obtaining_api_id

Ich gehe davon aus das bereits eine native (OHNE Docker oder Docker-Compose) Matrix-Synapse Instanz funktionsfähig z.B. auf Ubuntu 20.04 läuft.

Ebenso gehe ich davon aus das Backups vorhanden sind die im Notfall wiederhergestellt werden können. Kein Backup, kein Mitleid 🙂

Voraussetzung für die Mautrix-Telegram Bridge ist eine Docker und Docker-Compose installation auf der selben Maschine auf der auch Matrix-Synapse nativ läuft. Im Beispiel gehe ich hier von Ubuntu 20.04 aus.

Falls ihr kein "sudo" benutzen wollt streicht diesen Schritt, dann müsst Ihr aber in allen folgenden Befehlen das sudo weglassen.

apt install sudo

sudo apt install apt-transport-https ca-certificates curl software-properties-common

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu focal stable"

sudo apt update

sudo apt install docker-ce

sudo curl -L "https://github.com/docker/compose/releases/download/v2.4.1/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose

sudo chmod +x /usr/local/bin/docker-compose

Jetzt sind normalerweise Docker und Docker-Compose installiert und lauffähig.

Nun erstellen wir die Ordner für die Mautrix-Telegram Bridge im System. Am Beispiel erstelle ich die Ordner in /etc da hier auch die native Matrix-Synapse installation liegt. Natürlich kann dies auch in /opt oder irgendwo liegen.

mkdir /etc/mautrix-telegram && cd /etc/mautrix-telegram

mkdir bridge

mkdir db

Nun erstellen wir eine „docker-compose.yml“ Datei für Docker-Compose.

nano docker-compose.yml

Hier fügen wir folgenden Inhalt ein. Die stellen die ich mit 111, 222 oder 333 usw. kennzeichne bitte nach den eigenen bedürfnissen abändern. Die Inhalte müssen dann später an anderer stelle nochmal verwendet werden.

Ich habe unter "image: dock.mau.dev/mautrix/telegram:latest" latest gwählt. Hier kann man aber auch andere Release-Zweige wählen. Siehe "Docker images are hosted on dock.mau.dev. Available docker tags are generally :latest, :git tag, :git commit-amd64 and :git commit-arm64. The latest and git tag specific docker tags are manifests that contain both amd64 and arm64 images."

version: "3.7"services:  mautrix-telegram:    container_name: mautrix-telegram    image: dock.mau.dev/mautrix/telegram:latest    restart: unless-stopped    volumes:    - ./bridge:/data    # If synapse is running outside of docker, you'll need to expose the port.    # Note that in most cases you should either run everything inside docker    # or everything outside docker, rather than mixing docker things with    # non-docker things.    ports:    - "29317:29317"    # You'll also probably want this so the bridge can reach Synapse directly    # using something like `http://host.docker.internal:8008` as the address:    #extra_hosts:    #- "host.docker.internal:host-gateway"    # If synapse is in a different network, then add this container to that network.    #networks:    #- synapsenet# This is also a part of the networks thing above#networks:#  synapsenet:#    external:#      name: synapsenet  db:    image: postgres:13-alpine    restart: unless-stopped    environment:      POSTGRES_USER: mautrixtelegram111      POSTGRES_DATABASE: mautrixtelegram222      POSTGRES_PASSWORD: password333    volumes:    - ./db:/var/lib/postgresql/data

danach mit „STRG+X“ und „Y“ oder „J“ speichern und verlassen.

Nun können wir auch den „Mautrix-Telegram“ Container das erste mal starten.

docker-compose up mautrix-telegram

Es sollte nun unter /etc/mautrix-telegram/bridge/ eine config.yaml erstellt worden sein.

Falls die config.yaml in /etc/mautrix-telegram/ erstellt wurde müssen wir diese noch in /etc/mautrix-telegram/bridge/ verschieben. Bitte kontrolliert das. Falls die Datei bereits in /etc/mautrix-telegram/bridge/ ist überspringt dieses Schritt.

mv /etc/mautrix-telegram/config.yaml /etc/mautrix-telegram/bridge/

Wir stoppen den Mautrix-Telegram Container wieder um in ruhe die config.yaml zu bearbeiten.

docker-compose stop mautrix-telegram

nano /etc/mautrix-telegram/bridge/config.yaml

Die config.yaml sollte so aussehen. Ich habe wichtige stellen mit 111 oder 222 aus der docker-compose.yml oder XXX markiert die unbedingt nach den eigenen Angaben abgeändert werden sollten.

# Homeserver detailshomeserver:    # The address that this appservice can use to connect to the homeserver.    address: https://exampleXXX.comXXX    # The domain of the homeserver (for MXIDs, etc).    domain: exampleXXX.comXXX    # Whether or not to verify the SSL certificate of the homeserver.    # Only applies if address starts with https://    verify_ssl: true    asmux: false    # Number of retries for all HTTP requests if the homeserver isn't reachable.    http_retry_count: 4    # 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# 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    # When using https:// the TLS certificate and key files for the address.    tls_cert: false    tls_key: false    # The hostname and port where this appservice should listen.    hostname: 0.0.0.0    port: 29317    # The maximum body size of appservice API requests (from the homeserver) in mebibytes    # Usually 1 is enough, but on high-traffic bridges you might need to increase this to avoid 413s    max_body_size: 1    # The full URI to the database. SQLite and Postgres are supported.    # Format examples:    #   SQLite:   sqlite:///filename.db    #   Postgres: postgres://username:password@hostname/dbname    database: postgres://mautrixtelegram111:password333@db/mautrixtelegram222    # Additional arguments for asyncpg.create_pool() or sqlite3.connect()    # https://magicstack.github.io/asyncpg/current/api/index.html#asyncpg.pool.create_pool    # https://docs.python.org/3/library/sqlite3.html#sqlite3.connect    # For sqlite, min_size is used as the connection thread pool size and max_size is ignored.    database_opts:        min_size: 1        max_size: 10    # Public part of web server for out-of-Matrix interaction with the bridge.    # Used for things like login if the user wants to make sure the 2FA password isn't stored in    # the HS database.    public:        # Whether or not the public-facing endpoints should be enabled.        enabled: false        # The prefix to use in the public-facing endpoints.        prefix: /public        # The base URL where the public-facing endpoints are available. The prefix is not added        # implicitly.        external: https://example.com/public    # 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/v1        # The shared secret to authorize users of the API.        # Set to "generate" to generate and save a new token.        shared_secret: generate    # The unique ID of this appservice.    id: telegram    # Username of the appservice bot.    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.    bot_displayname: Telegram Bridge Bot    bot_avatar: mxc://maunium.net/tJCRmUyJDsgRNgqhOgoiHWbX    # Community ID for bridged users (changes registration file) and rooms.    # Must be created manually.    #    # Example: "+telegram:example.com". Set to false to disable.    community_id: false    # 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 telemetry config. Requires prometheus-client to be installed.metrics:    enabled: false    listen_port: 8000# Manhole config.manhole:    # Whether or not opening the manhole is allowed.    enabled: false    # The path for the unix socket.    path: /var/tmp/mautrix-telegram.manhole    # The list of UIDs who can be added to the whitelist.    # If empty, any UIDs can be specified in the open-manhole command.    whitelist:    - 0# Bridge configbridge:    # Localpart template of MXIDs for Telegram users.    # {userid} is replaced with the user ID of the Telegram user.    username_template: "telegram_{userid}"    # Localpart template of room aliases for Telegram portal rooms.    # {groupname} is replaced with the name part of the public channel/group invite link ( https://t.me/{} )    alias_template: "telegram_{groupname}"    # Displayname template for Telegram users.    # {displayname} is replaced with the display name of the Telegram user.    displayname_template: "{displayname} (Telegram)"    # Set the preferred order of user identifiers which to use in the Matrix puppet display name.    # In the (hopefully unlikely) scenario that none of the given keys are found, the numeric user    # ID is used.    #    # If the bridge is working properly, a phone number or an username should always be known, but    # the other one can very well be empty.    #    # Valid keys:    #   "full name"          (First and/or last name)    #   "full name reversed" (Last and/or first name)    #   "first name"    #   "last name"    #   "username"    #   "phone number"    displayname_preference:    - full name    - username    - phone number    # Maximum length of displayname    displayname_max_length: 100    # Remove avatars from Telegram ghost users when removed on Telegram. This is disabled by default    # as there's no way to determine whether an avatar is removed or just hidden from some users. If    # you're on a single-user instance, this should be safe to enable.    allow_avatar_remove: false    # Maximum number of members to sync per portal when starting up. Other members will be    # synced when they send messages. The maximum is 10000, after which the Telegram server    # will not send any more members.    # -1 means no limit (which means it's limited to 10000 by the server)    max_initial_member_sync: 100    # Whether or not to sync the member list in channels.    # If no channel admins have logged into the bridge, the bridge won't be able to sync the member    # list regardless of this setting.    sync_channel_members: true    # Whether or not to skip deleted members when syncing members.    skip_deleted_members: true    # Whether or not to automatically synchronize contacts and chats of Matrix users logged into    # their Telegram account at startup.    startup_sync: true    # Number of most recently active dialogs to check when syncing chats.    # Set to 0 to remove limit.    sync_update_limit: 0    # Number of most recently active dialogs to create portals for when syncing chats.    # Set to 0 to remove limit.    sync_create_limit: 30    # Whether or not to sync and create portals for direct chats at startup.    sync_direct_chats: false    # The maximum number of simultaneous Telegram deletions to handle.    # A large number of simultaneous redactions could put strain on your homeserver.    max_telegram_delete: 10    # Whether or not to automatically sync the Matrix room state (mostly unpuppeted displaynames)    # at startup and when creating a bridge.    sync_matrix_state: true    # Allow logging in within Matrix. If false, users can only log in using login-qr or the    # out-of-Matrix login website (see appservice.public config section)    allow_matrix_login: true    # Whether or not to bridge plaintext highlights.    # Only enable this if your displayname_template has some static part that the bridge can use to    # reliably identify what is a plaintext highlight.    plaintext_highlights: false    # Whether or not to make portals of publicly joinable channels/supergroups publicly joinable on Matrix.    public_portals: true    # Whether or not to use /sync to get presence, read receipts and typing notifications    # when double puppeting is enabled    sync_with_custom_puppets: true    # Whether or not to 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    # Servers to always allow double puppeting from    double_puppet_server_map:        example.comXXX: https://exampleXXX.comXXX    # 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, custom puppets will be enabled automatically for local users    # instead of users having to find an access token and run `login-matrix`    # manually.    # If using this for other servers than the bridge's server,    # you must also set the URL in the double_puppet_server_map.    login_shared_secret_map:        exampleXXX.comXXX: fooXXX PASSWORT AUS DER /etc/matrix-synapse/homeserver.yaml unter shared_secret XXX    # Set to false to disable link previews in messages sent to Telegram.    telegram_link_preview: true    # Whether or not the !tg join command should do a HTTP request    # to resolve redirects in invite links.    invite_link_resolve: false    # Use inline images instead of a separate message for the caption.    # N.B. Inline images are not supported on all clients (e.g. Element iOS/Android).    inline_images: false    # Maximum size of image in megabytes before sending to Telegram as a document.    image_as_file_size: 10    # Maximum size of Telegram documents in megabytes to bridge.    max_document_size: 100    # Enable experimental parallel file transfer, which makes uploads/downloads much faster by    # streaming from/to Matrix and using many connections for Telegram.    # Note that generating HQ thumbnails for videos is not possible with streamed transfers.    # This option uses internal Telethon implementation details and may break with minor updates.    parallel_file_transfer: false    # Whether or not created rooms should have federation enabled.    # If false, created portal rooms will never be federated.    federate_rooms: true    # Settings for converting animated stickers.    animated_sticker:        # Format to which animated stickers should be converted.        # disable - No conversion, send as-is (gzipped lottie)        # png - converts to non-animated png (fastest),        # gif - converts to animated gif        # webm - converts to webm video, requires ffmpeg executable with vp9 codec and webm container support        target: gif        # Arguments for converter. All converters take width and height.        args:            width: 256            height: 256            fps: 25 # only for webm and gif (2, 5, 10, 20 or 25 recommended)    # 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: true        # 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        # Database for the encryption data. If set to `default`, will use the appservice database.        database: default        # 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    # Whether or not to explicitly set the avatar and room name for private    # chat portal rooms. This will be implicitly enabled if encryption.default is true.    private_chat_portal_meta: false    # Whether or not the bridge should send a read receipt from the bridge bot when a message has    # been sent to Telegram.    delivery_receipts: false    # Whether or not delivery errors should be reported as messages in the Matrix room.    delivery_error_reports: false    # 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 pinned chats be moved to a specific tag in Matrix?    # The favorites tag is `m.favourite`.    pinned_tag: null    # Same as above for archived chats, the low priority tag is `m.lowpriority`.    archive_tag: null    # Whether or not mute status and tags should only be bridged when the portal room is created.    tag_only_on_create: true    # Should leaving the room on Matrix make the user leave on Telegram?    bridge_matrix_leave: true    # Should the user be kicked out of all portals when logging out of the bridge?    kick_on_logout: true    # Settings for backfilling messages from Telegram.    backfill:        # Whether or not the Telegram ghosts of logged in Matrix users should be        # invited to private chats when backfilling history from Telegram. This is        # usually needed to prevent rate limits and to allow timestamp massaging.        invite_own_puppet: true        # Maximum number of messages to backfill without using a takeout.        # The first time a takeout is used, the user has to manually approve it from a different        # device. If initial_limit or missed_limit are higher than this value, the bridge will ask        # the user to accept the takeout after logging in before syncing any chats.        takeout_limit: 100        # Maximum number of messages to backfill initially.        # Set to 0 to disable backfilling when creating portal, or -1 to disable the limit.        #        # N.B. Initial backfill will only start after member sync. Make sure your        #      max_initial_member_sync is set to a low enough value so it doesn't take forever.        initial_limit: 0        # Maximum number of messages to backfill if messages were missed while the bridge was        # disconnected. Note that this only works for logged in users and only if the chat isn't        # older than sync_update_limit        # Set to 0 to disable backfilling missed messages.        missed_limit: 50        # If using double puppeting, should notifications be disabled        # while the initial backfill is in progress?        disable_notifications: false        # Whether or not to enable backfilling in normal groups.        # Normal groups have numerous technical problems in Telegram, and backfilling normal groups        # will likely cause problems if there are multiple Matrix users in the group.        normal_groups: false    # Overrides for base power levels.    initial_power_level_overrides:        user: {}        group: {}    # Whether to bridge Telegram bot messages as m.notices or m.texts.    bot_messages_as_notices: true    bridge_notices:        # Whether or not Matrix bot messages (type m.notice) should be bridged.        default: false        # List of user IDs for whom the previous flag is flipped.        # e.g. if bridge_notices.default is false, notices from other users will not be bridged, but        #      notices from users listed here will be bridged.        exceptions:        - "@importantbot:example.com"    # The formats to use when sending messages to Telegram via the relay bot.    # Text msgtypes (m.text, m.notice and m.emote) support HTML, media msgtypes don't.    #    # Available variables:    #   $sender_displayname - The display name of the sender (e.g. Example User)    #   $sender_username    - The username (Matrix ID localpart) of the sender (e.g. exampleuser)    #   $sender_mxid        - The Matrix ID of the sender (e.g. @exampleuser:example.com)    #   $message            - The message content    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: $message"        m.image: "<b>$sender_displayname</b> sent an image: $message"        m.audio: "<b>$sender_displayname</b> sent an audio file: $message"        m.video: "<b>$sender_displayname</b> sent a video: $message"        m.location: "<b>$sender_displayname</b> sent a location: $message"    # Telegram doesn't have built-in emotes, this field specifies how m.emote's from authenticated    # users are sent to telegram. All fields in message_formats are supported. Additionally, the    # Telegram user info is available in the following variables:    #    $displayname - Telegram displayname    #    $username    - Telegram username (may not exist)    #    $mention     - Telegram @username or displayname mention (depending on which exists)    emote_format: "* $mention $formatted_body"    # The formats to use when sending state events to Telegram via the relay bot.    #    # Variables from `message_formats` that have the `sender_` prefix are available without the prefix.    # In name_change events, `$prev_displayname` is the previous displayname.    #    # Set format to an empty string to disable the messages for that event.    state_event_formats:        join: "<b>$displayname</b> joined the room."        leave: "<b>$displayname</b> left the room."        name_change: "<b>$prev_displayname</b> changed their name to <b>$displayname</b>"    # Filter rooms that can/can't be bridged. Can also be managed using the `filter` and    # `filter-mode` management commands.    #    # Filters do not affect direct chats.    # An empty blacklist will essentially disable the filter.    filter:        # Filter mode to use. Either "blacklist" or "whitelist".        # If the mode is "blacklist", the listed chats will never be bridged.        # If the mode is "whitelist", only the listed chats can be bridged.        mode: blacklist        # The list of group/channel IDs to filter.        list: []    # The prefix for commands. Only required in non-management rooms.    command_prefix: "!tg"    # 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 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: ""    # Send each message separately (for readability in some clients)    management_room_multiple_messages: 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:        "domain": "relaybot"        "exampleXXX.comXXX": "full"        "@adminMATRIXUSERADMINXXX:exampleXXX.comXXX": "admin"    # Options related to the message relay Telegram bot.    relaybot:        private_chat:            # List of users to invite to the portal when someone starts a private chat with the bot.            # If empty, private chats with the bot won't create a portal.            invite: []            # Whether or not to bridge state change messages in relaybot private chats.            state_changes: true            # When private_chat_invite is empty, this message is sent to users /starting the            # relaybot. Telegram's "markdown" is supported.            message: This is a Matrix bridge relaybot and does not support direct chats        # List of users to invite to all group chat portals created by the bridge.        group_chat_invite: []        # Whether or not the relaybot should not bridge events in unbridged group chats.        # If false, portals will be created when the relaybot receives messages, just like normal        # users. This behavior is usually not desirable, as it interferes with manually bridging        # the chat to another room.        ignore_unbridged_group_chat: true        # Whether or not to allow creating portals from Telegram.        authless_portals: true        # Whether or not to allow Telegram group admins to use the bot commands.        whitelist_group_admins: true        # Whether or not to ignore incoming events sent by the relay bot.        ignore_own_incoming_events: true        # List of usernames/user IDs who are also allowed to use the bot commands.        whitelist:        - myusername        - 12345678# Telegram configtelegram:    # 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    # 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    # Device info sent to Telegram.    device_info:        # "auto" = OS name+version.        device_model: auto        # "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: ""# Python logging configuration.## See section 16.7.2 of the Python documentation for more info:# https://docs.python.org/3.6/library/logging.config.html#configuration-dictionary-schemalogging:    version: 1    formatters:        colored:            (): mautrix_telegram.util.ColorFormatter            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"        normal:            format: "[%(asctime)s] [%(levelname)s@%(name)s] %(message)s"    handlers:        file:            class: logging.handlers.RotatingFileHandler            formatter: normal            filename: ./mautrix-telegram.log            maxBytes: 10485760            backupCount: 10        console:            class: logging.StreamHandler            formatter: colored    loggers:        mau:            level: DEBUG        telethon:            level: INFO        aiohttp:            level: INFO    root:        level: DEBUG        handlers: [file, console]

mit „STRG+X“ und „Y“ oder „J“ speichern und verlassen.

Nun starten wir den Container noch einmal. Es sollte nun eine „registration.yaml“ in /etc/mautrix-telegram/bridge/ erzeugt werden.

docker-compose up mautrix-telegram

Falls die registration.yaml in /etc/mautrix-telegram/ erstellt wurde müssen wir diese noch in /etc/mautrix-telegram/bridge/ verschieben. Bitte kontrolliert das. Falls die Datei bereits in /etc/mautrix-telegram/bridge/ ist überspringt dieses Schritt.

mv /etc/mautrix-telegram/registration.yaml /etc/mautrix-telegram/bridge/

Der Mautrix-Telegram Container wird wieder gestoppt.

docker-compose stop mautrix-telegram

Jetzt muss der Appservice von Mautrix-Telegram auch Matrix-Synapse bekannt gemacht werden. Dies machen wir indem wir die homeserver.yaml editieren.

nano /etc/matrix-synapse/homeserver.yaml

unter der Rubrik „app_service_config_files“ ändern wir folgendes ab. Dies sollte dann so aussehen:

# A list of application service config files to use#app_service_config_files:  - /etc/mautrix-telegram/bridge/registration.yaml

mit „STRG+X“ und „Y“ oder „J“ speichern und verlassen.

Jetzt muss Matrix-Synapse neu gestartet werden.

systemctl restart matrix-synapse.service

Als nächstes benötigen wir einen Telegram API-Key und einen API-Hash. Diesen bekommen wir hier.

Man benötigt einen aktiven Telegram Account z.B. auf dem Smartphone (App). Auf der Seite https://my.telegram.org/auth trägt man seine Rufnummer ein. Man erhält nun von Telegram einen Key auf seinen Telegram-Account. Diesen trägt man dann ein.

Im nächsten Schritt wählt man NICHT Delete sondern API-Development-Tools.

Hier wählt man bei Name z.B. Matrixbot und bei Betriebssystem Desktop. Dann wählt man Absenden und bestätigt das ganze. Im Anschluss erhält man seinen API-Key und den API-Hash.

Diesen müssen wir jetzt noch in der config.yaml eintragen.

nano /etc/mautrix-telegram/bridge/config.yaml

unter Telegram config sollte das dann so aussehen.

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

mit „STRG+X“ und „Y“ oder „J“ speichern und verlassen.

Jetzt kann die Bridge final hochgefahren werden und sollte nun lauffähig sein.

docker-compose up -d

Den Mautrix-Telegram Bot kann man nun in einen neuen Raum/Direktnachricht einladen. In Element eine neue Direktnachricht starten und nach @telegrambot:DEINEDOMAIN.de suchen und in den Raum einladen.

In Element im Raum mit dem Telegrambot können wir uns nun (nochmal) registrieren.

register +4955555555555 NAME 

Der Bot sollte dies nun Bestätigen. Wenn dies der Fall ist kann es losgehen. Wenn alles funktioniert kann die App auf dem Smartphone gelöscht werden da der Bot funktioniert und übernommen hat.

mit help im Chat mit dem Bot kann man sich auch noch weitere Infos holen was die Kommunikation mit dem Bot betrifft.

Die Bridge startet übrigens bei Neustart des Servers automatisch da in der docker-compose.yml die Option "restart: unless-stopped" gewählt wurde.

Upgrades kann man übrigens im Verzeichnis /etc/mautrix-telegram/ mit

docker-compose pull

und

docker-compose up -d

machen.

Ich hoffe ich konnte dies hier etwas verständlich ausführen und euch weiter helfen.

Noch ein dickes BIGUP und Danke an Tulir Asokan für seine großartige Arbeit!