-``/whatsapp unlink``
- Ends the link and deletes the session. When WhatsApp is disconnected,
- the phone does not get the logout, so remove the device in Linked
- devices on the phone.
-
-The answers go only to the client that asked, and the commands do not go
-to the agent, so the agent never gets the phone number or the code. The
-chat gets only the notes that WhatsApp is linked or unlinked.
-
-The session is ``whatsapp/session.db`` in the data directory, with mode
-0600 in a directory with mode 0700. It gives full access to the WhatsApp
-account, so the daemon refuses the file when its mode is not 0600. The
-shell of the agent runs as the user, so it can read the session. If the
-session leaks, remove the linked device in WhatsApp on the phone, and
-the session stops working. Without the file, WhatsApp is not linked.
-
-The daemon reads the text messages of the private chats and the groups,
-from other people and from the user. It does not read media, reactions,
-edits, deletions, view-once and disappearing messages, or the history
-from before the link. The messages of one chat form one batch until the
-chat is quiet for 20 seconds, for 2 minutes or 50 messages at the most.
-Each batch goes to the chat of the agent as one work message that starts
-with ``[WhatsApp]``, with the name and the ID of the chat, and the time,
-the sender, and the text of each message. The messages of the user show
-as ``You``. ``whatsapp/state.json``, with mode 0600, keeps the batches
-that are not in the chat yet, so they survive a restart, and the records
-of the sends. A crash just after a batch goes to the chat can make the
-batch repeat once.
-
-A batch of a private chat with a message of another person starts a
-turn, and so does a batch of a group with a message that mentions the
-user or replies to a message of the user. The other batches go to the
-chat with no turn, and the agent sees them at its next turn. A batch
-that starts a turn ends with a line that tells the agent to end its turn
-with an empty reply when nothing in the batch needs the user. No client
-shows an empty reply, so such a batch gives no message in Telegram. The
-terminal client shows each batch, and Telegram shows none.
-
-The phone number of the user never goes to the chat: a mention of the
-user shows as ``@you``, the number shows as ``OWN``, and the chat of the
-user with itself is not read. But the IDs of the other chats go to the
-chat and to the model, because the agent needs them to send. The ID of a
-private chat holds the phone number of the contact, such as
-``15550002222@s.whatsapp.net``, and the ID of a group can hold the
-number of the person who made it.
-
-While the daemon is stopped or disconnected, the WhatsApp servers keep
-the messages for the linked device and send them at the next connection.
-They keep them only for a limited time, so a long stop can lose
-messages. These messages form batches by their original times, as live
-messages do. The daemon waits for the end of this catch-up, or one
-minute at the most, and then gives all its batches to the agent in one
-turn, not one turn for each chat. The batches of ``whatsapp/state.json``
-at the start wait for the first catch-up in the same way.
-
-The agent finds a chat with the tool ``whatsapp_find``: it gives the
-contacts and the groups whose name holds a text, with no regard to case
-and accents, with their IDs. The names of the contacts come from the
-session, and the names of the groups from WhatsApp, kept in memory for
-one hour. The names arrive from the phone some minutes after the link,
-and until then the tool says that they are not ready. The agent sends a
-text message with the tool ``whatsapp_send``, only when the user asks
-for it. Each send has an ID that the agent gives: a repeated call with
-the same ID gives the answer of the first call and sends nothing. The
-state file keeps the last 1000 send records. When the daemon stops
-during a send, the result is not known, and the tool tells the agent to
-ask the user to look at the chat in WhatsApp. Without a link, both tools
-tell the agent to ask the user to run ``/whatsapp pair PHONE``. Only the
-agent has the WhatsApp tools, not its subagents.
-
-Each batch of a group goes to the chat, also with no turn, and the
-memory tree summarizes it with model calls, which use the quota.
-
-The root manages source routes with ``route(source, agent)``,
-``unroute(source)``, and ``routes()``, only after the user agrees. A
-source is ``whatsapp:CHAT-ID``, with the ID from ``whatsapp_find`` or a
-``[WhatsApp]`` message, and the agent must be its child. The root keeps
-the map in ``agent/routes.json`` with mode 0600. Children and subagents
-have no route tools. There is no command to change routes.
-
-When the session holds a linked device, the daemon connects at its
-start. If the first connection fails, it tries again after 2 seconds,
-then doubles the wait up to 5 minutes. The inbox and commands stay
-active during each wait. An unlink or a logout stops these retries.
-After a network failure of an open connection, the library connects
-again by itself. When a disconnection lasts 10 minutes, all clients get
-one notice, and one more when the connection comes back. When WhatsApp
-ends the connection for good, for example because another program uses
-the same session, all clients get a notice at once. When the user
-removes the device in the phone, the daemon deletes the session and
-tells all clients one time.
-
-*************************
- Import WhatsApp history
-*************************
-
-Stop the daemon and finish all subagents before an import. Export each
-chat from WhatsApp as a ZIP with ``_chat.txt``. Keep the chat name in
-the ZIP name, such as ``WhatsApp Chat - Example.zip``. Read the plan
-first:
projects / onechat / blobdiff