# Homeserver details. homeserver: # The address that this appservice can use to connect to the homeserver. address: http://synapse:8008 # The address to mautrix-wsproxy (which should usually be next to the homeserver behind a reverse proxy). # Only the /_matrix/client/unstable/fi.mau.as_sync websocket endpoint is used on this address. # # Set to null to disable using the websocket. When not using the websocket, make sure hostname and port are set in the appservice section. websocket_proxy: wss://synapse:8008 # How often should the websocket be pinged? Pinging will be disabled if this is zero. ping_interval_seconds: 0 # The domain of the homeserver (also known as server_name, used for MXIDs, etc). domain: {{matrix_server_name}} # What software is the homeserver running? # Standard Matrix homeservers like Synapse, Dendrite and Conduit should just use "standard" here. software: standard # Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246? async_media: false # Application service host/registration related details. # Changing these values requires regeneration of the registration. appservice: # The hostname and port where this appservice should listen. # The default method of deploying mautrix-imessage is using a websocket proxy, so it doesn't need a http server # To use a http server instead of a websocket, set websocket_proxy to null in the homeserver section, # and set the port below to a real port. hostname: 0.0.0.0 port: null # Optional TLS certificates to listen for https instead of http connections. tls_key: null tls_cert: null # Database config. database: # The database type. Only "sqlite3-fk-wal" is supported. type: sqlite3-fk-wal # SQLite database path. A raw file path is supported, but `file:?_txlock=immediate` is recommended. uri: file:mautrix-imessage.db?_txlock=immediate # The unique ID of this appservice. id: imessage # Appservice bot details. bot: # Username of the appservice bot. username: imessagebot # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty # to leave display name/avatar as-is. displayname: iMessage bridge bot avatar: mxc://maunium.net/tManJEpANASZvDVzvRvhILdX # 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: true # 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" # iMessage connection config imessage: # Available platforms: # * mac: Standard Mac connector, requires full disk access and will ask for AppleScript and contacts permission. # * ios: Jailbreak iOS connector when using with Brooklyn. # * android: Equivalent to ios, but for use with the Android SMS wrapper app. # * mac-nosip: Mac without SIP connector, runs Barcelona as a subprocess. platform: mac # Path to the Barcelona executable for the mac-nosip connector imessage_rest_path: darwin-barcelona-mautrix # Additional arguments to pass to the mac-nosip connector imessage_rest_args: [] # The mode for fetching contacts in the no-SIP connector. # The default mode is `ipc` which will ask Barcelona. However, recent versions of Barcelona have removed contact support. # You can specify `mac` to use Contacts.framework directly instead of through Barcelona. # You can also specify `disable` to not try to use contacts at all. contacts_mode: ipc # Whether to log the contents of IPC payloads log_ipc_payloads: false # For the no-SIP connector, hackily set the user account locale before starting Barcelona. hacky_set_locale: null # A list of environment variables to add for the Barcelona process (as NAME=value strings) environment: [] # Path to unix socket for Barcelona communication. unix_socket: mautrix-imessage.sock # Interval to ping Barcelona at. The process will exit if Barcelona doesn't respond in time. ping_interval_seconds: 15 # Should media on disk be deleted after bridging to Matrix? delete_media_after_upload: false bluebubbles_url: bluebubbles_password: # Segment settings for collecting some debug data. segment: key: null user_id: null hacky_startup_test: identifier: null message: null response_message: null key: null echo_mode: false send_on_startup: false periodic_resolve: -1 # Bridge config bridge: # The user of the bridge. user: "@you:example.com" {% raw %} # Localpart template of MXIDs for iMessage users. # {{.}} is replaced with the phone number or email of the iMessage user. username_template: imessage_{{.}} # Displayname template for iMessage users. # {{.}} is replaced with the contact list name (if available) or username (phone number or email) of the iMessage user. displayname_template: "{{.}} (iMessage)" # Should the bridge create a space and add bridged rooms to it? personal_filtering_spaces: false {% endraw %} # Whether or not the bridge should send a read receipt from the bridge bot when a message has been # sent to iMessage. delivery_receipts: false # Whether or not the bridge should send the message status as a custom # com.beeper.message_send_status event. message_status_events: true # Whether or not the bridge should send error notices via m.notice events # when a message fails to bridge. send_error_notices: true # The maximum number of seconds between the message arriving at the # homeserver and the bridge attempting to send the message. This can help # prevent messages from being bridged a long time after arriving at the # homeserver which could cause confusion in the chat history on the remote # network. Set to 0 to disable. max_handle_seconds: 0 # Device ID to include in m.bridge data, read by client-integrated Android SMS. # Not relevant for standalone bridges nor iMessage. device_id: null # Whether or not to sync with custom puppets to receive EDUs that are not normally sent to appservices. sync_with_custom_puppets: false # 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 # Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth # # If set, double puppeting will be enabled automatically instead of the user # having to find an access token and run `login-matrix` manually. login_shared_secret: null # Homeserver URL for the double puppet. If null, will use the URL set in homeserver -> address double_puppet_server_url: null # Backfill settings backfill: # Should backfilling be enabled at all? enable: true # Maximum number of messages to backfill for new portal rooms. initial_limit: 100 # Maximum age of chats to sync in days. initial_sync_max_age: 0.5 # If a backfilled chat is older than this number of hours, mark it as read even if it's unread on iMessage. # Set to -1 to let any chat be unread. unread_hours_threshold: 720 ######################################################################### # The settings below are only applicable if you are: # # # # 1. Using batch sending, which is no longer supported in Synapse. # # 2. Running the bridge in backfill-only mode connecting to another # # instance for portal creation via websocket commands. # # # # In other words, unless you are Beeper, the rest of the backfill # # section very likely does not apply to you. # ######################################################################### # Is this bridge only meant for backfilling chats? only_backfill: false # 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 losing context. immediate: # The maximum number of events to backfill initially. max_events: 25 # 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: 50 batch_delay: 5 # Last Month - start_days_ago: 30 max_batch_events: 100 batch_delay: 10 # Last 3 months - start_days_ago: 90 max_batch_events: 250 batch_delay: 10 # The start of time - start_days_ago: -1 max_batch_events: 500 batch_delay: 10 # Whether or not the bridge should periodically resync chat and contact info. periodic_sync: true # Should the bridge look through joined rooms to find existing portals if the database has none? # This can be used to recover from bridge database loss. find_portals_if_db_empty: false # Media viewer settings. See https://gitlab.com/beeper/media-viewer for more info. # Used to send media viewer links instead of full files for attachments that are too big for MMS. media_viewer: # The address to the media viewer. If null, media viewer links will not be used. url: null # The homeserver domain to pass to the media viewer to use for downloading media. # If null, will use the server name configured in the homeserver section. homeserver: null # The minimum number of bytes in a file before the bridge switches to using the media viewer when sending MMS. # Note that for unencrypted files, this will use a direct link to the homeserver rather than the media viewer. sms_min_size: 409600 # Same as above, but for iMessages. imessage_min_size: 52428800 # Template text when inserting media viewer URLs. # %s is replaced with the actual URL. template: "Full size attachment: %s" # Should we convert heif images to jpeg before re-uploading? This increases # compatibility, but adds generation loss (reduces quality). convert_heif: true # Should we convert tiff images to jpeg before re-uploading? This increases # compatibility, but adds generation loss (reduces quality). convert_tiff: true # Modern Apple devices tend to use h265 encoding for video, which is a licensed standard and therefore not # supported by most major browsers. If enabled, all video attachments will be converted according to the # ffmpeg args. convert_video: enabled: false # Convert to h264 format (supported by all major browsers) at decent quality while retaining original # audio. Modify these args to do whatever encoding/quality you want. ffmpeg_args: ["-c:v", "libx264", "-preset", "faster", "-crf", "22", "-c:a", "copy"] extension: "mp4" mime_type: "video/mp4" # The prefix for commands. command_prefix: "!im" # Should we rewrite the sender in a DM to match the chat GUID? # This is helpful when the sender ID shifts depending on the device they use, since # the bridge is unable to add participants to the chat post-creation. force_uniform_dm_senders: true # Should SMS chats always be in the same room as iMessage chats with the same phone number? disable_sms_portals: false # iMessage has weird IDs for group chats, so getting all messages in the same MMS group chat into the same Matrix room # may require rerouting some messages based on the fake ReplyToGUID that iMessage adds. reroute_mms_group_replies: false # Whether or not created rooms should have federation enabled. # If false, created portal rooms will never be federated. federate_rooms: true # Send captions in the same message as images using MSC2530? # This is currently not supported in most clients. caption_in_message: false # Whether to explicitly set the avatar and room name for private chat portal rooms. # If set to `default`, this will be enabled in encrypted rooms and disabled in unencrypted rooms. # If set to `always`, all DM rooms will have explicit names and avatars set. # If set to `never`, DM rooms will never have names and avatars set. private_chat_portal_meta: default # End-to-bridge encryption support options. # See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html 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 or not 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 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 # 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 # 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 {% raw %} # Settings for relay mode relay: # Whether relay mode should be allowed. enabled: false # A list of user IDs and server names who are allowed to be relayed through this bridge. Use * to allow everyone. whitelist: [] # The formats to use when relaying messages to iMessage. message_formats: m.text: "{{ .Sender.Displayname }}: {{ .Message }}" m.notice: "{{ .Sender.Displayname }}: {{ .Message }}" m.emote: "* {{ .Sender.Displayname }} {{ .Message }}" m.file: "{{ .Sender.Displayname }} sent a file: {{ .FileName }}" m.image: "{{ .Sender.Displayname }} sent an image: {{ .FileName }}" m.audio: "{{ .Sender.Displayname }} sent an audio file: {{ .FileName }}" m.video: "{{ .Sender.Displayname }} sent a video: {{ .FileName }}" {% endraw %} # 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-imessage.log max_size: 100 max_backups: 10 compress: true # This may be used by external config managers. mautrix-imessage does not read it, but will carry it across configuration migrations. revision: 0