summaryrefslogtreecommitdiff
path: root/docs/CHAT-APPLICATION.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/CHAT-APPLICATION.txt')
-rw-r--r--docs/CHAT-APPLICATION.txt76
1 files changed, 67 insertions, 9 deletions
diff --git a/docs/CHAT-APPLICATION.txt b/docs/CHAT-APPLICATION.txt
index 9d281ed..7b4dc40 100644
--- a/docs/CHAT-APPLICATION.txt
+++ b/docs/CHAT-APPLICATION.txt
@@ -37,7 +37,11 @@ WHAT EXISTS
and inbox; the canonical RSA OpenPGP key is not used for chat encryption.
History defaults to zero messages. Authenticated counters show total, sent,
- and received messages. Load 0 to 50 recent messages, then page backwards.
+ and received messages. Choose 0 to N recent messages, where N is the current
+ conversation total, or page backwards for older messages. Counts refresh when
+ the history input is focused, history is requested, or a send is acknowledged.
+ Large selections are fetched and verified in batches of at most 50; that is
+ a per-request resource bound, not a user-visible 50-message selection limit.
Reload, lock, or leaving clears the application's in-memory references and
visible messages. A separate authenticated session expires after 30 minutes.
There is no automatic background polling, notification, or remote logout.
@@ -73,15 +77,16 @@ LOCAL PREREQUISITES AND COMMANDS
cargo stack chat
- Open:
-
- http://127.0.0.1:9080/#setup
+ Open http://127.0.0.1:9080/ and choose OWNER SETUP, labeled for the owner
+ only. The direct http://127.0.0.1:9080/#setup link also works.
Read CHAT_SETUP_TOKEN from your root .env locally and paste it into the owner
setup form. Choose an owner display name and a strong unique password. Save
the downloaded file, reopen it, and unlock it. That establishes the owner
public identity. The setup token stops authorizing setup once an owner exists.
- It does not become an owner login or a key recovery mechanism. Never publish
+ It does not become an owner login or a key recovery mechanism. OWNER SETUP
+ stays visible; once an owner exists, it explains how to open the existing
+ owner file or reset after loss instead of silently replacing the key. Never publish
the owner private file or its password. Keep both in your private KeePassXC
database, along with a separately protected backup of that database.
@@ -97,6 +102,52 @@ LOCAL PREREQUISITES AND COMMANDS
operational review, and a main-branch merge remain separate work. Do not
expose this experimental development service through a public proxy.
+OWNER FILE LOSS AND BACKEND RESET
+
+ A setup token grants registration permission. It cannot recover the private
+ key inside a lost owner file. If that file and its backups are gone, existing
+ messages cannot be decrypted with a newly generated identity. The reset below
+ intentionally starts a fresh chat service and clears all stored messages,
+ encrypted profiles, conversations, counters, and the owner registration.
+ It preserves the root .env and any previously exported backup archives.
+ It does not claim forensic erasure of backups, snapshots, or OS copies.
+
+ Run these commands locally at the stack root for the current development
+ build. There is no reset operation in the HTTP API. Filesystem access to
+ the private chat directory is the administrative boundary. A future production
+ package must expose the same options through its prebuilt server binary;
+ do not install Rust on the VPS for these development commands.
+
+ Read the current public fingerprint, even if you have lost the private file:
+
+ cargo stack chat --owner-fingerprint
+
+ Stop the chat server with Control-C in its terminal, then explicitly pass
+ that full fingerprint to the destructive reset command:
+
+ cargo stack chat --reset-owner PASTE_CURRENT_OWNER_FINGERPRINT_HERE
+
+ A fingerprint mismatch refuses without deleting data. The server and reset
+ process share a filesystem lock; reset also requires the loopback service
+ port to be free. This prevents resetting a running service, including a
+ development process launched before the lock was added. Online snapshots and
+ reading the public owner fingerprint remain available while chat is running.
+
+ Restart:
+
+ cargo stack chat
+
+ Choose OWNER SETUP and use the existing CHAT_SETUP_TOKEN from the same root
+ .env to generate, save, and reopen a fresh owner file. Back that file and its
+ password up in KeePassXC. Visitors must create fresh chat files too: their
+ previous files pin the former owner key and are correctly rejected after
+ replacement. A reset cannot prove continuity with the lost key.
+
+ If an old owner file is found later, an old encrypted backup may still allow
+ recovering its original conversations in an isolated restored installation.
+ The reset does not remove existing exported archives, and it never substitutes
+ a new key into old ciphertext or old visitor files.
+
FILE AND MESSAGE CRYPTOGRAPHY
OpenPGP v6, ML-KEM-1024 + X448 encryption, ML-DSA-87 + Ed448 signatures,
@@ -178,7 +229,7 @@ AUTHENTICATION AND STORAGE
Send retries are deliberate; messages are not automatically resent.
Limits: 8192 UTF-8 bytes per text, 16384 bytes per signed payload, 65536 base64
- characters per stored ciphertext, 50 history rows per request, 1000 visitor
+ characters per stored ciphertext, 50 history rows per API request, 1000 visitor
identities, 10000 messages per conversation, and a one-billion-character
total message-ciphertext budget. At most 60 authentication challenges per
global minute window, 128 pending challenges, 256 active sessions, and four
@@ -187,7 +238,8 @@ AUTHENTICATION AND STORAGE
protection against determined traffic, account creation, CPU, or disk attacks.
Public-key and profile storage, indexes, journals, and backups add overhead to
the ciphertext budget. Monitor actual disk use. No public abuse controls,
- deletion UI, rotation UI, blocklist, or password-change UI are implemented.
+ deletion UI, in-place key rotation UI, blocklist, or password-change UI are
+ implemented. Lost-owner recovery uses the explicit backend reset above.
BROWSER STATE AND LIMITATIONS
@@ -273,6 +325,8 @@ INTERFACE AND SITE STYLE
amber and muted green accents. The LibreJS badge stays yellow with its
keyboard-accessible warning. Small screens keep readable form controls and
fit the ASCII rules to the available width instead of shrinking all text.
+ Scrolling belongs to the root viewport at the screen edge; the logo has no
+ inner scroll container. JavaScript licenses sit below the LibreJS badge.
No remote fonts, images, or additional scripts are required.
LICENSES, SOURCE, AND VERIFICATION
@@ -340,9 +394,13 @@ LICENSES, SOURCE, AND VERIFICATION
The crypto browser probe fails closed without browser CSPRNG entropy and on
unknown WASI imports. The application browser test uses real WASI/OpenSSL
cryptography, protected file downloads and reopen, incorrect passwords,
- signed sends/replies, safe text display, counts, zero-history, pagination,
+ signed sends/replies, safe text display, counts, zero-history, loading all
+ 54 fixture messages through 50+4 batches, pagination,
lost-response retry deduplication, reload, explicit lock, origin rejection,
- live database snapshot restoration with both original identity files, in-flight
+ live database snapshot restoration with both original identity files, owner
+ setup/access controls, refusing reset while running or with a mismatched
+ fingerprint, successful backend reset and fresh registration, rejecting old
+ visitor key pins, in-flight
lock, back/forward restoration, and checks for plaintext persistence or private
credential uploads.
Native tests cover authorization, challenge reuse, expiry, locked sessions,