]> git.giacomolli.uk - onechat/blobdiff - README.rst
Show the linked device as OneChat on the phone
[onechat] / README.rst
index b17cd64349b05077ef6a0c4d6e7db8976c90e154..93be7846e95dbf24831375cf43c8d2e3a9817d04 100644 (file)
@@ -186,7 +186,10 @@ device. The terminal client and Telegram take three commands:
    Linked devices, tap Link a device, then tap Link with phone number
    instead, and enter the code. The code expires in about 2 minutes, and
    the same command gives a new code. When the link succeeds, the daemon
-   answers with the linked number.
+   answers with the linked number. Linked devices on the phone shows the
+   device as OneChat. The name applies at the pairing, so an existing
+   link keeps its old name until ``/whatsapp unlink`` and a new
+   ``/whatsapp pair PHONE``.
 
 ``/whatsapp status``
    Shows the link: not linked, linked and connected, or linked and
@@ -217,8 +220,9 @@ 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. A crash just
-after a batch goes to the chat can make the batch repeat once.
+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
@@ -237,6 +241,30 @@ 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.