matrix-synapse-shared-secret-auth VS whatsapp

bridge:    # Localpart template of MXIDs for WhatsApp users.    # {{.}} is replaced with the phone number of the WhatsApp user.    usernametemplate: whatsapp{{.}}    # Displayname template for WhatsApp users.    # {{.PushName}}     - nickname set by the WhatsApp user    # {{.BusinessName}} - validated WhatsApp business name    # {{.Phone}}        - phone number (international format)    # The following variables are also available, but will cause problems on multi-user instances:    # {{.FullName}}  - full name from contact list    # {{.FirstName}} - first name from contact list    displayname_template: "{{if .PushName}}{{.PushName}}{{else if .BusinessName}}{{.BusinessName}}{{else}}{{.JID}}{{end}} (WA)"    # Should the bridge create a space for each logged-in user and add bridged rooms to it?    # Users who logged in before turning this on should run !wa sync space to create and fill the space for the first time.    personal_filtering_spaces: false    # Should the bridge send a read receipt from the bridge bot when a message has been sent to WhatsApp?    delivery_receipts: false    # Should incoming calls send a message to the Matrix room?    call_start_notices: true    # Should another user's cryptographic identity changing send a message to Matrix?    identity_change_notices: false    portal_message_buffer: 128    # Settings for handling history sync payloads.    history_sync:        # Should the bridge create portals for chats in the history sync payload?        create_portals: true        # 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        # 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        # 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        # 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        # 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.        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.            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:        # - 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: 20              batch_delay: 5            # Last Month            - start_days_ago: 30              max_batch_events: 50              batch_delay: 10            # Last 3 months            - start_days_ago: 90              max_batch_events: 100              batch_delay: 10            # The start of time            - start_days_ago: -1              max_batch_events: 500              batch_delay: 10    # Should puppet avatars be fetched from the server even if an avatar is already set?    user_avatar_sync: true    # Should Matrix users leaving groups be bridged to WhatsApp?    bridge_matrix_leave: true    # Should the bridge sync with double puppeting to receive EDUs that aren't normally sent to appservices.    sync_with_custom_puppets: true    # 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    # 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    # Send the presence as "available" to whatsapp when users start typing on a portal.    # This works as a workaround for homeservers that do not support presence, and allows    # users to see when the whatsapp user on the other side is typing during a conversation.    send_presence_on_typing: false    # Should the bridge always send "active" delivery receipts (two gray ticks on WhatsApp)    # even if the user isn't marked as online (e.g. when presence bridging isn't enabled)?    #    # By default, the bridge acts like WhatsApp web, which only sends active delivery    # receipts when it's in the foreground.    force_active_delivery_receipts: false    # Servers to always allow double puppeting from    double_puppet_server_map:        example.com: https://example.com    # Allow using double puppeting from any server with a valid client .well-known file.    double_puppet_allow_discovery: false    # Shared secrets for https://github.com/devture/matrix-synapse-shared-secret-auth    #    # 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_map:        example.com: foobar    # Should the bridge explicitly set the avatar and room name for private chat portal rooms?    private_chat_portal_meta: false    # 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.    resend_bridge_info: false    # When using double puppeting, should muted chats be muted in Matrix?    mute_bridging: false    # When using double puppeting, should archived chats be moved to a specific tag in Matrix?    # Note that WhatsApp unarchives chats when a message is received, which will also be mirrored to Matrix.    # This can be set to a tag (e.g. m.lowpriority), or null to disable.    archive_tag: null    # Same as above, but for pinned chats. The favorite tag is called m.favourite    pinned_tag: null    # Should mute status and tags only be bridged when the portal room is created?    tag_only_on_create: true    # Should WhatsApp status messages be bridged into a Matrix room?    # Disabling this won't affect already created status broadcast rooms.    enable_status_broadcast: true    # Should the status broadcast room be muted and moved into low priority by default?    # This is only applied when creating the room, the user can unmute it later.    mute_status_broadcast: true    # Tag to apply to the status broadcast room.    status_broadcast_tag: m.lowpriority    # Should the bridge use thumbnails from WhatsApp?    # They're disabled by default due to very low resolution.    whatsapp_thumbnail: false    # Allow invite permission for user. User can invite any bots to room with whatsapp    # users (private chat and groups)    allow_user_invite: false    # Whether or not created rooms should have federation enabled.    # If false, created portal rooms will never be federated.    federate_rooms: true    # Whether to enable disappearing messages in groups. If enabled, then the expiration time of    # the messages will be determined by the first user to read the message, rather than individually.    # If the bridge only has a single user, this can be turned on safely.    disappearing_messages_in_groups: false    # Should the bridge never send alerts to the bridge management room?    # These are mostly things like the user being logged out.    disable_bridge_alerts: false    # Should the bridge detect URLs in outgoing messages, ask the homeserver to generate a preview,    # and send it to WhatsApp? URL previews can always be sent using the com.beeper.linkpreviews    # key in the event content even if this is disabled.    url_previews: false

The best you can do now is run whatsapp apk on an emulator or spare device, then auth that with the matrix bridge, then you can avoid needing to use whatsapp clients on daily drivers. Works decently well: https://github.com/mautrix/whatsapp

For WhatsApp, there's a thing called 'bridges' that can link your WhatsApp chats to other chat services that you can access from the device. One example is this bridge that bring chats to open-sourced Matrix protocol, which you can use Hydrogen browser interface to access on the phone. Another bridges to a Discord server that might suit well with this community-made interface.

I suggest you to take a look at matrix and its bridges, like Mautrix Whatsapp. If you don't have competence / time to setup a matrix server, Element Matrix Services host it for you, and you can use WhatsApp, telegram and signal all with a client, without tracking or shitty things from fb

I use it as a one-stop-shop for messaging. I setup a Synapse server ~5 years ago and since then have convinced many of my close family and friends to join my server (or another). Now many of the folks I want to chat with are regular users of Matrix. For some of my stone-age friends that are still on WhatsApp, I run a bridge [1] so that I don't need to look beyond my Matrix client to see WhatsApp messages. For other random SMS messages, I use the dated SmsMatrix [2] to push text messages so I can see/reply from Matrix. Beyond that, I also use Matrix to connect to several open source communities (e.g. Mailu.io [3]).

1. https://github.com/mautrix/whatsapp

you might be looking for this? https://github.com/mautrix/whatsapp/blob/master/example-config.yaml

One option could be to have an old phone tuning android WhatsApp and enable the multi-device beta to use that for web access and access on that other phone, although I don't know if they support the multi device feature either. If you're somewhat technical you could also use an android VM instead of a physical phone, and if you're comfortable with self hosting docker you can use the matrix whatsapp bridge to use WhatsApp without having to install it on your device. https://github.com/mautrix/whatsapp and https://github.com/spantaleev/matrix-docker-ansible-deploy