1
0
Fork 0
mirror of https://github.com/YunoHost-Apps/mautrix_whatsapp_ynh.git synced 2024-09-03 19:46:01 +02:00

Upgrade to v0.9.0

This commit is contained in:
yunohost-bot 2023-07-17 06:16:48 +00:00
parent 905f934442
commit fc86890cac
5 changed files with 52 additions and 63 deletions

View file

@ -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

View file

@ -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

View file

@ -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

View file

@ -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:
@ -451,7 +440,7 @@ logging:
format: pretty-colored
- type: file
format: json
filename: /var/log/__APP__/__APP__.log
filename: ./logs/mautrix-whatsapp.log
max_size: 100
max_backups: 10
compress: true

View file

@ -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",