Browse Source

Update comments in example config

Tulir Asokan 3 years ago
parent
commit
d19703a02d
1 changed files with 25 additions and 25 deletions
  1. 25 25
      example-config.yaml

+ 25 - 25
example-config.yaml

@@ -56,7 +56,7 @@ appservice:
     hs_token: "This value is generated when generating the registration"
 
 metrics:
-    # Whether or not to enable prometheus metrics
+    # Enable prometheus metrics?
     enabled: false
     # IP and port where the metrics listener should be. The path is always /metrics
     listen: 127.0.0.1:8001
@@ -83,60 +83,59 @@ bridge:
     # {{.FirstName}} - first name from contact list
     displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"
 
-    # Whether or not the bridge should send a read receipt from the bridge bot when a message has been
-    # sent to WhatsApp. If fetch_message_on_timeout is enabled, a successful post-timeout fetch will
-    # trigger a read receipt too.
+    # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?
     delivery_receipts: false
 
-    portal_message_buffer: 128
-
-    # Whether or not to send call start/end notices to Matrix.
+    # Should notices of incoming calls be sent to Matrix?
     call_notices:
         start: true
         end: true
 
+    # Settings for handling history sync payloads. These settings only apply right after login,
+    # because the phone only sends the history sync data once, and there's no way to re-request it
+    # (other than logging out and back in again).
     history_sync:
-        # Whether to create portals from history sync payloads from WhatsApp.
+        # Should the bridge create portals for chats in the history sync payload?
         create_portals: true
         # Maximum age of chats in seconds to create portals for. Set to 0 to create portals for all chats in sync payload.
         max_age: 604800
-        # Whether to enable backfilling history sync payloads from WhatsApp using batch sending
+        # Enable backfilling history sync payloads from WhatsApp using batch sending?
         # This requires a server with MSC2716 support, which is currently an experimental feature in synapse.
         # It can be enabled by setting experimental_features -> enable_msc2716 to true in homeserver.yaml.
         backfill: false
-        # Whether to use custom puppet for backfilling.
-        # In order to use this, the custom puppets must be in the appservice's user ID namespace.
+        # Use double puppets for backfilling?
+        # In order to use this, the double puppets must be in the appservice's user ID namespace
+        # (because the bridge can't use the double puppet access token with batch sending).
         double_puppet_backfill: false
-        # Whether the client should request a full sync from the phone when logging in.
+        # Should the bridge request a full sync from the phone when logging in?
         # This bumps the size of history syncs from 3 months to 1 year.
         request_full_sync: false
-    # Whether or not puppet avatars should be fetched from the server even if an avatar is already set.
+    # Should puppet avatars be fetched from the server even if an avatar is already set?
     user_avatar_sync: true
-    # Whether or not Matrix users leaving groups should be bridged to WhatsApp
+    # Should Matrix users leaving groups be bridged to WhatsApp?
     bridge_matrix_leave: true
 
-    # Whether or not to sync with custom puppets to receive EDUs that
-    # are not normally sent to appservices.
+    # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.
     sync_with_custom_puppets: true
-    # Whether or not to update the m.direct account data event when double puppeting is enabled.
+    # Should the bridge 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
-    # When double puppeting is enabled, users can use `!wa toggle` to change whether or not
+    # When double puppeting is enabled, users can use `!wa toggle` to change whether
     # presence and read receipts are bridged. These settings set the default values.
     # Existing users won't be affected when these are changed.
     default_bridge_receipts: true
     default_bridge_presence: true
     # Shared secret for https://github.com/devture/matrix-synapse-shared-secret-auth
     #
-    # If set, custom puppets will be enabled automatically for local users
+    # If set, double puppeting will be enabled automatically for local users
     # instead of users having to find an access token and run `login-matrix`
     # manually.
     login_shared_secret: null
 
-    # Whether to explicitly set the avatar and room name for private chat portal rooms.
+    # Should the bridge explicitly set the avatar and room name for private chat portal rooms?
     private_chat_portal_meta: false
-    # Whether Matrix m.notice-type messages should be bridged.
+    # Should Matrix m.notice-type messages be bridged?
     bridge_notices: true
     # 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.
@@ -149,13 +148,13 @@ bridge:
     archive_tag: null
     # Same as above, but for pinned chats. The favorite tag is called m.favourite
     pinned_tag: null
-    # Whether or not mute status and tags should only be bridged when the portal room is created.
+    # Should mute status and tags only be bridged when the portal room is created?
     tag_only_on_create: true
-    # Whether or not WhatsApp status messages should be bridged into a Matrix room.
+    # Should WhatsApp status messages be bridged into a Matrix room?
     # Disabling this won't affect already created status broadcast rooms.
     enable_status_broadcast: true
 
-    # Whether or not thumbnails from WhatsApp should be sent.
+    # Should the bridge use thumbnails from WhatsApp?
     # They're disabled by default due to very low resolution.
     whatsapp_thumbnail: false
 
@@ -237,6 +236,7 @@ logging:
     # The directory for log files. Will be created if not found.
     directory: ./logs
     # Available variables: .Date for the file date and .Index for different log files on the same day.
+    # Set this to null to disable logging to file.
     file_name_format: "{{.Date}}-{{.Index}}.log"
     # Date format for file names in the Go time format: https://golang.org/pkg/time/#pkg-constants
     file_date_format: 2006-01-02
@@ -244,6 +244,6 @@ logging:
     file_mode: 0600
     # Timestamp format for log entries in the Go time format.
     timestamp_format: Jan _2, 2006 15:04:05
-    # Minimum severity for log messages.
+    # Minimum severity for log messages printed to stdout/stderr. This doesn't affect the log file.
     # Options: debug, info, warn, error, fatal
     print_level: debug