mirror of
				https://github.com/kevinveenbirkenbach/computer-playbook.git
				synced 2025-10-31 10:19:09 +00:00 
			
		
		
		
	Huge role refactoring/cleanup. Other commits will propably follow. Because some bugs will exist. Still important for longrun and also for auto docs/help/slideshow generation
This commit is contained in:
		
							
								
								
									
										373
									
								
								roles/web-app-matrix/templates/mautrix/imessage.config.yml.j2
									
									
									
									
									
										Normal file
									
								
							
							
						
						
									
										373
									
								
								roles/web-app-matrix/templates/mautrix/imessage.config.yml.j2
									
									
									
									
									
										Normal file
									
								
							| @@ -0,0 +1,373 @@ | ||||
| # 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: {{applications[application_id].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:<path>?_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 desktop-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/desktop-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 | ||||
		Reference in New Issue
	
	Block a user