example-config.yaml 16 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306
  1. # Homeserver details.
  2. homeserver:
  3. # The address that this appservice can use to connect to the homeserver.
  4. address: https://example.com
  5. # The domain of the homeserver (for MXIDs, etc).
  6. domain: example.com
  7. # Is the homeserver actually mautrix-asmux?
  8. asmux: false
  9. # The URL to push real-time bridge status to.
  10. # If set, the bridge will make POST requests to this URL whenever a user's whatsapp connection state changes.
  11. # The bridge will use the appservice as_token to authorize requests.
  12. status_endpoint: null
  13. # Endpoint for reporting per-message status.
  14. message_send_checkpoint_endpoint: null
  15. # Does the homeserver support https://github.com/matrix-org/matrix-spec-proposals/pull/2246?
  16. async_media: false
  17. # Application service host/registration related details.
  18. # Changing these values requires regeneration of the registration.
  19. appservice:
  20. # The address that the homeserver can use to connect to this appservice.
  21. address: http://localhost:29318
  22. # The hostname and port where this appservice should listen.
  23. hostname: 0.0.0.0
  24. port: 29318
  25. # Database config.
  26. database:
  27. # The database type. "sqlite3" and "postgres" are supported.
  28. type: sqlite3
  29. # The database URI.
  30. # SQLite: File name is enough. https://github.com/mattn/go-sqlite3#connection-string
  31. # Postgres: Connection string. For example, postgres://user:password@host/database?sslmode=disable
  32. # To connect via Unix socket, use something like postgres:///dbname?host=/var/run/postgresql
  33. uri: mautrix-whatsapp.db
  34. # Maximum number of connections. Mostly relevant for Postgres.
  35. max_open_conns: 20
  36. max_idle_conns: 2
  37. # Maximum connection idle time and lifetime before they're closed. Disabled if null.
  38. # Parsed with https://pkg.go.dev/time#ParseDuration
  39. max_conn_idle_time: null
  40. max_conn_lifetime: null
  41. # Settings for provisioning API
  42. provisioning:
  43. # Prefix for the provisioning API paths.
  44. prefix: /_matrix/provision
  45. # Shared secret for authentication. If set to "generate", a random secret will be generated,
  46. # or if set to "disable", the provisioning API will be disabled.
  47. shared_secret: generate
  48. # Segment API key to enable analytics tracking for web server
  49. # endpoints. Set to null to disable.
  50. # Currently the only events are login start, QR code retrieve, and login
  51. # success/failure.
  52. segment_key: null
  53. # The unique ID of this appservice.
  54. id: whatsapp
  55. # Appservice bot details.
  56. bot:
  57. # Username of the appservice bot.
  58. username: whatsappbot
  59. # Display name and avatar for bot. Set to "remove" to remove display name/avatar, leave empty
  60. # to leave display name/avatar as-is.
  61. displayname: WhatsApp bridge bot
  62. avatar: mxc://maunium.net/NeXNQarUbrlYBiPCpprYsRqr
  63. # Whether or not to receive ephemeral events via appservice transactions.
  64. # Requires MSC2409 support (i.e. Synapse 1.22+).
  65. # You should disable bridge -> sync_with_custom_puppets when this is enabled.
  66. ephemeral_events: false
  67. # Authentication tokens for AS <-> HS communication. Autogenerated; do not modify.
  68. as_token: "This value is generated when generating the registration"
  69. hs_token: "This value is generated when generating the registration"
  70. # Prometheus config.
  71. metrics:
  72. # Enable prometheus metrics?
  73. enabled: false
  74. # IP and port where the metrics listener should be. The path is always /metrics
  75. listen: 127.0.0.1:8001
  76. # Config for things that are directly sent to WhatsApp.
  77. whatsapp:
  78. # Device name that's shown in the "WhatsApp Web" section in the mobile app.
  79. os_name: Mautrix-WhatsApp bridge
  80. # Browser name that determines the logo shown in the mobile app.
  81. # Must be "unknown" for a generic icon or a valid browser name if you want a specific icon.
  82. # List of valid browser names: https://github.com/tulir/whatsmeow/blob/2a72655ef600a7fd7a2e98d53ec6da029759c4b8/binary/proto/def.proto#L1582-L1594
  83. browser_name: unknown
  84. # Bridge config
  85. bridge:
  86. # Localpart template of MXIDs for WhatsApp users.
  87. # {{.}} is replaced with the phone number of the WhatsApp user.
  88. username_template: whatsapp_{{.}}
  89. # Displayname template for WhatsApp users.
  90. # {{.PushName}} - nickname set by the WhatsApp user
  91. # {{.BusinessName}} - validated WhatsApp business name
  92. # {{.Phone}} - phone number (international format)
  93. # The following variables are also available, but will cause problems on multi-user instances:
  94. # {{.FullName}} - full name from contact list
  95. # {{.FirstName}} - first name from contact list
  96. displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"
  97. # Should the bridge create a space for each logged-in user and add bridged rooms to it?
  98. # Users who logged in before turning this on should run `!wa sync space` to create and fill the space for the first time.
  99. personal_filtering_spaces: false
  100. # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
  101. delivery_receipts: false
  102. # Should incoming calls send a message to the Matrix room?
  103. call_start_notices: true
  104. # Should another user's cryptographic identity changing send a message to Matrix?
  105. identity_change_notices: false
  106. portal_message_buffer: 128
  107. # Settings for handling history sync payloads. These settings only apply right after login,
  108. # because the phone only sends the history sync data once, and there's no way to re-request it
  109. # (other than logging out and back in again).
  110. history_sync:
  111. # Should the bridge create portals for chats in the history sync payload?
  112. create_portals: true
  113. # Maximum age of chats in seconds to create portals for. Set to 0 to create portals for all chats in sync payload.
  114. max_age: 604800
  115. # Enable backfilling history sync payloads from WhatsApp using batch sending?
  116. # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
  117. # It can be enabled by setting experimental_features -> msc2716_enabled to true in homeserver.yaml.
  118. # Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
  119. # There are also still some issues in Synapse's federation implementation.
  120. backfill: false
  121. # Use double puppets for backfilling?
  122. # In order to use this, the double puppets must be in the appservice's user ID namespace
  123. # (because the bridge can't use the double puppet access token with batch sending).
  124. # This only affects double puppets on the local server, double puppets on other servers will never be used.
  125. double_puppet_backfill: false
  126. # Should the bridge request a full sync from the phone when logging in?
  127. # This bumps the size of history syncs from 3 months to 1 year.
  128. request_full_sync: false
  129. # Should puppet avatars be fetched from the server even if an avatar is already set?
  130. user_avatar_sync: true
  131. # Should Matrix users leaving groups be bridged to WhatsApp?
  132. bridge_matrix_leave: true
  133. # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
  134. sync_with_custom_puppets: true
  135. # Should the bridge update the m.direct account data event when double puppeting is enabled.
  136. # Note that updating the m.direct event is not atomic (except with mautrix-asmux)
  137. # and is therefore prone to race conditions.
  138. sync_direct_chat_list: false
  139. # When double puppeting is enabled, users can use `!wa toggle` to change whether
  140. # presence and read receipts are bridged. These settings set the default values.
  141. # Existing users won't be affected when these are changed.
  142. default_bridge_receipts: true
  143. default_bridge_presence: true
  144. # Send the presence as "available" to whatsapp when users start typing on a portal.
  145. # This works as a workaround for homeservers that do not support presence, and allows
  146. # users to see when the whatsapp user on the other side is typing during a conversation.
  147. send_presence_on_typing: false
  148. # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)
  149. # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?
  150. #
  151. # By default, the bridge acts like WhatsApp web, which only sends active delivery
  152. # receipts when it's in the foreground.
  153. force_active_delivery_receipts: false
  154. # Servers to always allow double puppeting from
  155. double_puppet_server_map:
  156. example.com: https://example.com
  157. # Allow using double puppeting from any server with a valid client .well-known file.
  158. double_puppet_allow_discovery: false
  159. # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth
  160. #
  161. # If set, double puppeting will be enabled automatically for local users
  162. # instead of users having to find an access token and run `login-matrix`
  163. # manually.
  164. login_shared_secret_map:
  165. example.com: foobar
  166. # Should the bridge explicitly set the avatar and room name for private chat portal rooms?
  167. private_chat_portal_meta: false
  168. # Should Matrix m.notice-type messages be bridged?
  169. bridge_notices: true
  170. # Set this to true to tell the bridge to re-send m.bridge events to all rooms on the next run.
  171. # This field will automatically be changed back to false after it, except if the config file is not writable.
  172. resend_bridge_info: false
  173. # When using double puppeting, should muted chats be muted in Matrix?
  174. mute_bridging: false
  175. # When using double puppeting, should archived chats be moved to a specific tag in Matrix?
  176. # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.
  177. # This can be set to a tag (e.g. m.lowpriority), or null to disable.
  178. archive_tag: null
  179. # Same as above, but for pinned chats. The favorite tag is called m.favourite
  180. pinned_tag: null
  181. # Should mute status and tags only be bridged when the portal room is created?
  182. tag_only_on_create: true
  183. # Should WhatsApp status messages be bridged into a Matrix room?
  184. # Disabling this won't affect already created status broadcast rooms.
  185. enable_status_broadcast: true
  186. # Should the status broadcast room be muted and moved into low priority by default?
  187. # This is only applied when creating the room, the user can unmute/untag it later.
  188. mute_status_broadcast: true
  189. # Should the bridge use thumbnails from WhatsApp?
  190. # They're disabled by default due to very low resolution.
  191. whatsapp_thumbnail: false
  192. # Allow invite permission for user. User can invite any bots to room with whatsapp
  193. # users (private chat and groups)
  194. allow_user_invite: false
  195. # Whether or not created rooms should have federation enabled.
  196. # If false, created portal rooms will never be federated.
  197. federate_rooms: true
  198. # Whether to enable disappearing messages in groups. If enabled, then the expiration time of
  199. # the messages will be determined by the first user to read the message, rather than individually.
  200. # If the bridge only has a single user, this can be turned on safely.
  201. disappearing_messages_in_groups: false
  202. # Should the bridge never send alerts to the bridge management room?
  203. # These are mostly things like the user being logged out.
  204. disable_bridge_alerts: false
  205. # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,
  206. # and send it to WhatsApp? URL previews can always be sent using the `com.beeper.linkpreviews`
  207. # key in the event content even if this is disabled.
  208. url_previews: false
  209. # The prefix for commands. Only required in non-management rooms.
  210. command_prefix: "!wa"
  211. # Messages sent upon joining a management room.
  212. # Markdown is supported. The defaults are listed below.
  213. management_room_text:
  214. # Sent when joining a room.
  215. welcome: "Hello, I'm a WhatsApp bridge bot."
  216. # Sent when joining a management room and the user is already logged in.
  217. welcome_connected: "Use `help` for help."
  218. # Sent when joining a management room and the user is not logged in.
  219. welcome_unconnected: "Use `help` for help or `login` to log in."
  220. # Optional extra text sent when joining a management room.
  221. additional_help: ""
  222. # End-to-bridge encryption support options.
  223. #
  224. # See https://docs.mau.fi/bridges/general/end-to-bridge-encryption.html for more info.
  225. encryption:
  226. # Allow encryption, work in group chat rooms with e2ee enabled
  227. allow: false
  228. # Default to encryption, force-enable encryption in all portals the bridge creates
  229. # This will cause the bridge bot to be in private chats for the encryption to work properly.
  230. # It is recommended to also set private_chat_portal_meta to true when using this.
  231. default: false
  232. # Options for automatic key sharing.
  233. key_sharing:
  234. # Enable key sharing? If enabled, key requests for rooms where users are in will be fulfilled.
  235. # You must use a client that supports requesting keys from other users to use this feature.
  236. allow: false
  237. # Require the requesting device to have a valid cross-signing signature?
  238. # This doesn't require that the bridge has verified the device, only that the user has verified it.
  239. # Not yet implemented.
  240. require_cross_signing: false
  241. # Require devices to be verified by the bridge?
  242. # Verification by the bridge is not yet implemented.
  243. require_verification: true
  244. # Permissions for using the bridge.
  245. # Permitted values:
  246. # relay - Talk through the relaybot (if enabled), no access otherwise
  247. # user - Access to use the bridge to chat with a WhatsApp account.
  248. # admin - User level and some additional administration tools
  249. # Permitted keys:
  250. # * - All Matrix users
  251. # domain - All users on that homeserver
  252. # mxid - Specific user
  253. permissions:
  254. "*": relay
  255. "example.com": user
  256. "@admin:example.com": admin
  257. # Settings for relay mode
  258. relay:
  259. # Whether relay mode should be allowed. If allowed, `!wa set-relay` can be used to turn any
  260. # authenticated user into a relaybot for that chat.
  261. enabled: false
  262. # Should only admins be allowed to set themselves as relay users?
  263. admin_only: true
  264. # The formats to use when sending messages to WhatsApp via the relaybot.
  265. message_formats:
  266. m.text: "<b>{{ .Sender.Displayname }}</b>: {{ .Message }}"
  267. m.notice: "<b>{{ .Sender.Displayname }}</b>: {{ .Message }}"
  268. m.emote: "* <b>{{ .Sender.Displayname }}</b> {{ .Message }}"
  269. m.file: "<b>{{ .Sender.Displayname }}</b> sent a file"
  270. m.image: "<b>{{ .Sender.Displayname }}</b> sent an image"
  271. m.audio: "<b>{{ .Sender.Displayname }}</b> sent an audio file"
  272. m.video: "<b>{{ .Sender.Displayname }}</b> sent a video"
  273. m.location: "<b>{{ .Sender.Displayname }}</b> sent a location"
  274. # Logging config.
  275. logging:
  276. # The directory for log files. Will be created if not found.
  277. directory: ./logs
  278. # Available variables: .Date for the file date and .Index for different log files on the same day.
  279. # Set this to null to disable logging to file.
  280. file_name_format: "{{.Date}}-{{.Index}}.log"
  281. # Date format for file names in the Go time format: https://golang.org/pkg/time/#pkg-constants
  282. file_date_format: "2006-01-02"
  283. # Log file permissions.
  284. file_mode: 0o600
  285. # Timestamp format for log entries in the Go time format.
  286. timestamp_format: "Jan _2, 2006 15:04:05"
  287. # Minimum severity for log messages printed to stdout/stderr. This doesn't affect the log file.
  288. # Options: debug, info, warn, error, fatal
  289. print_level: debug