Retry the first WhatsApp connection

[onechat] / README.rst

diff --git a/README.rst b/README.rst
index 5f4266a025b0a19f4805bbdd124a3c403c66b11a..0cc4b1e194d9a7deaf3a32d8281b1c0bbc4b67de 100644 (file)
--- a/README.rst
+++ b/README.rst
@@ -73,7 +73,10 @@ Start the daemon, and then the client in another terminal:
 .. code:: console
 
    onechat daemon
-   onechat chat
+   onechat
+
+``onechat`` with no command is the same as ``onechat chat``. ``onechat
+help`` lists the commands.
 
 The daemon owns the root agent in ``agent/`` in the data directory and
 listens on the Unix socket ``onechat.sock`` there. In the client, each
@@ -146,7 +149,7 @@ does not collect the package while the service uses it:
 .. code:: console
 
    nix build --out-link result-service
-   systemctl --user link --force "$(realpath result-service/share/systemd/user/onechat.service)"
+   systemctl --user link --force "$PWD/result-service/share/systemd/user/onechat.service"
    systemctl --user edit onechat.service
 
 In the editor, set the data directory with this drop-in. Replace
@@ -192,18 +195,19 @@ the service:
    systemctl --user daemon-reload
    systemctl --user enable --now onechat.service
    systemctl --user status onechat.service
-   ONECHAT_DIR=DATA_DIR ./result-service/bin/onechat chat
+   ONECHAT_DIR=DATA_DIR ./result-service/bin/onechat
    journalctl --user -u onechat.service -f
 
-After ``git pull``, build with the same result link, link the unit
-again, reload the user manager, and restart the service:
+After a pull, update the package and unit with:
 
 .. code:: console
 
-   nix build --out-link result-service
-   systemctl --user link --force "$(realpath result-service/share/systemd/user/onechat.service)"
-   systemctl --user daemon-reload
-   systemctl --user restart onechat.service
+   git pull
+   bin/service-update
+
+The script builds with the same ``result-service`` link, reloads the
+user manager, and restarts the service only if it is active. The unit
+link follows ``result-service``, so no new link is needed.
 
 The service starts with the user manager at login, not at boot without a
 login. To stop it, or also remove its start at login:
@@ -353,12 +357,16 @@ 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.
 
 When the session holds a linked device, the daemon connects at its
-start, and after a network failure it 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.
+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, logout, or pair command 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.
 
 ***********
  Schedules