mirror of
https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh.git
synced 2024-09-03 19:46:01 +02:00
Merge pull request #108 from YunoHost-Apps/ci-auto-update-v0.9.0
Upgrade to version 0.9.0
This commit is contained in:
commit
e8b7e666d6
7 changed files with 53 additions and 64 deletions
|
@ -25,7 +25,7 @@ Therefore, [Synapse for YunoHost](https://github.com/YunoHost-Apps/synapse_ynh)
|
|||
** Attention: always backup and restore the Yunohost matrix_synapse et mautrix_whatsapp apps together!**
|
||||
|
||||
|
||||
**Shipped version:** 0.8.6~ynh1
|
||||
**Shipped version:** 0.9.0~ynh1
|
||||
## Disclaimers / important information
|
||||
|
||||
## List of known public services
|
||||
|
|
|
@ -25,7 +25,7 @@ C'est pourquoi [Synapse for YunoHost](https://github.com/YunoHost-Apps/synapse_y
|
|||
** Attention : sauvegardez et restaurez toujours les deux applications Yunohost matrix_synapse et mautrix_whatsapp en même temps!**
|
||||
|
||||
|
||||
**Version incluse :** 0.8.6~ynh1
|
||||
**Version incluse :** 0.9.0~ynh1
|
||||
## Avertissements / informations importantes
|
||||
|
||||
## Liste de passerelles publiques
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.8.6/mautrix-whatsapp-amd64
|
||||
SOURCE_SUM=a9e3e1c920dbd5ba35a6a91209d267fa9a8f98ce43c81d56c5126e965fcd8eaa
|
||||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.9.0/mautrix-whatsapp-amd64
|
||||
SOURCE_SUM=27b5d3ee0cada177207b662072b42923956e38a9c10c4e167eeca17881f3bffb
|
||||
SOURCE_SUM_PRG=sha256sum
|
||||
SOURCE_IN_SUBDIR=false
|
||||
SOURCE_FILENAME=mautrix-whatsapp
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.8.6/mautrix-whatsapp-arm64
|
||||
SOURCE_SUM=dcac55fc3336a251ec6dc6f28b76199833505310f03ec526de5aee87852736aa
|
||||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.9.0/mautrix-whatsapp-arm64
|
||||
SOURCE_SUM=dc475a2af45988d6d428af18c5f2a30da24930201e0e667a0b749a198a3bd02d
|
||||
SOURCE_SUM_PRG=sha256sum
|
||||
SOURCE_IN_SUBDIR=false
|
||||
SOURCE_FILENAME=mautrix-whatsapp
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.8.6/mautrix-whatsapp-arm
|
||||
SOURCE_SUM=a76127e5e3ddd6ce99c578ad29a22a9b9609462c7a47dc8b9e2f6b4ab94f5396
|
||||
SOURCE_URL=https://github.com/mautrix/whatsapp/releases/download/v0.9.0/mautrix-whatsapp-arm
|
||||
SOURCE_SUM=22c28d17ec868c4579e8ed64e092b0947a268c82ed9714d3ae45ace05b477fd8
|
||||
SOURCE_SUM_PRG=sha256sum
|
||||
SOURCE_IN_SUBDIR=false
|
||||
SOURCE_FILENAME=mautrix-whatsapp
|
||||
|
|
|
@ -83,7 +83,7 @@ whatsapp:
|
|||
os_name: __OS_NAME__
|
||||
# Browser name that determines the logo shown in the mobile app.
|
||||
# Must be "unknown" for a generic icon or a valid browser name if you want a specific icon.
|
||||
# List of valid browser names: https://github.com/tulir/whatsmeow/blob/8b34d886d543b72e5f4699cf5b2797f68d598f78/binary/proto/def.proto#L38-L51
|
||||
# List of valid browser names: https://github.com/tulir/whatsmeow/blob/efc632c008604016ddde63bfcfca8de4e5304da9/binary/proto/def.proto#L43-L64
|
||||
browser_name: __BROWSER_NAME__
|
||||
# Bridge config
|
||||
bridge:
|
||||
|
@ -114,20 +114,14 @@ bridge:
|
|||
portal_message_buffer: 128
|
||||
# Settings for handling history sync payloads.
|
||||
history_sync:
|
||||
# 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 -> msc2716_enabled to true in homeserver.yaml.
|
||||
# Note that prior to Synapse 1.49, there were some bugs with the implementation, especially if using event persistence workers.
|
||||
# There are also still some issues in Synapse's federation implementation.
|
||||
backfill: false
|
||||
# Should the bridge create portals for chats in the history sync payload?
|
||||
# This has no effect unless backfill is enabled.
|
||||
create_portals: true
|
||||
# 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).
|
||||
# This only affects double puppets on the local server, double puppets on other servers will never be used.
|
||||
double_puppet_backfill: false
|
||||
# Enable backfilling history sync payloads from WhatsApp?
|
||||
backfill: true
|
||||
# The maximum number of initial conversations that should be synced.
|
||||
# Other conversations will be backfilled on demand when receiving a message or when initiating a direct chat.
|
||||
max_initial_conversations: -1
|
||||
# Maximum number of messages to backfill in each conversation.
|
||||
# Set to -1 to disable limit.
|
||||
message_count: 50
|
||||
# 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
|
||||
|
@ -141,51 +135,42 @@ bridge:
|
|||
size_mb_limit: null
|
||||
# This is presumably the local storage quota, which may affect what the phone includes in the history sync blob.
|
||||
storage_quota_mb: null
|
||||
# Settings for media requests. If the media expired, then it will not
|
||||
# be on the WA servers.
|
||||
# Media can always be requested by reacting with the ♻️ (recycle) emoji.
|
||||
# These settings determine if the media requests should be done
|
||||
# automatically during or after backfill.
|
||||
media_requests:
|
||||
# Should expired media be automatically requested from the server as
|
||||
# part of the backfill process?
|
||||
auto_request_media: true
|
||||
# Whether to request the media immediately after the media message
|
||||
# is backfilled ("immediate") or at a specific time of the day
|
||||
# ("local_time").
|
||||
request_method: immediate
|
||||
# If request_method is "local_time", what time should the requests
|
||||
# be sent (in minutes after midnight)?
|
||||
request_local_time: 120
|
||||
# The maximum number of initial conversations that should be synced.
|
||||
# Other conversations will be backfilled on demand when the start PM
|
||||
# provisioning endpoint is used or when a message comes in from that
|
||||
# chat.
|
||||
max_initial_conversations: -1
|
||||
# If this value is greater than 0, then if the conversation's last
|
||||
# message was more than this number of hours ago, then the conversation
|
||||
# will automatically be marked it as read.
|
||||
# Conversations that have a last message that is less than this number
|
||||
# of hours ago will have their unread status synced from WhatsApp.
|
||||
# If this value is greater than 0, then if the conversation's last message was more than
|
||||
# this number of hours ago, then the conversation will automatically be marked it as read.
|
||||
# Conversations that have a last message that is less than this number of hours ago will
|
||||
# have their unread status synced from WhatsApp.
|
||||
unread_hours_threshold: 0
|
||||
# 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 loosing context.
|
||||
###############################################################################
|
||||
# The settings below are only applicable for backfilling using batch sending, #
|
||||
# which is no longer supported in Synapse. #
|
||||
###############################################################################
|
||||
|
||||
# Settings for media requests. If the media expired, then it will not be on the WA servers.
|
||||
# Media can always be requested by reacting with the ♻️ (recycle) emoji.
|
||||
# These settings determine if the media requests should be done automatically during or after backfill.
|
||||
media_requests:
|
||||
# Should expired media be automatically requested from the server as part of the backfill process?
|
||||
auto_request_media: true
|
||||
# Whether to request the media immediately after the media message is backfilled ("immediate")
|
||||
# or at a specific time of the day ("local_time").
|
||||
request_method: immediate
|
||||
# If request_method is "local_time", what time should the requests be sent (in minutes after midnight)?
|
||||
request_local_time: 120
|
||||
# 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 number of concurrent backfill workers to create for immediate
|
||||
# backfills. Note that using more than one worker could cause the
|
||||
# room list to jump around since there are no guarantees about the
|
||||
# order in which the backfills will complete.
|
||||
# The number of concurrent backfill workers to create for immediate backfills.
|
||||
# Note that using more than one worker could cause the room list to jump around
|
||||
# since there are no guarantees about the order in which the backfills will complete.
|
||||
worker_count: 1
|
||||
# The maximum number of events to backfill initially.
|
||||
max_events: 10
|
||||
# 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:
|
||||
# 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.
|
||||
|
@ -369,6 +354,10 @@ bridge:
|
|||
delete_on_device_delete: false
|
||||
# Periodically delete megolm sessions when 2x max_age has passed since receiving the session.
|
||||
periodically_delete_expired: false
|
||||
# Delete inbound megolm sessions that don't have the received_at field used for
|
||||
# automatic ratcheting and expired session deletion. This is meant as a migration
|
||||
# to delete old keys prior to the bridge update.
|
||||
delete_outdated_inbound: false
|
||||
# What level of device verification should be required from users?
|
||||
#
|
||||
# Valid levels:
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
"en": "Matrix / Synapse puppeting bridge for WhatsApp",
|
||||
"fr": "Passerelle Matrix / Synapse pour WhatsApp"
|
||||
},
|
||||
"version": "0.8.6~ynh1",
|
||||
"version": "0.9.0~ynh1",
|
||||
"url": "https://github.com/mautrix/whatsapp",
|
||||
"upstream": {
|
||||
"license": "AGPL-3.0-or-later",
|
||||
|
|
Loading…
Add table
Reference in a new issue