Remember each text's thread root on the device

littlefox commented

2026-10-22 14:41:29 +00:00

Owner

Approved for 0.7 (D-063). Follows up a note on #243.

The first time a channel's newest texts are grouped into threads (#242, step 1a), each text is walked up to its thread's root. That costs one server call per text in a chain. Kom::thread_root remembers roots within a session, but they are lost on reload.

Keep text → root on the device:

in IndexedDB in the browser and in a file on the desktop, like the search index (#239/#267);
per server and person;
with a size cap, dropping the least recently used entries;
dropped when the server says the text is gone.

That makes the walk once per device instead of once per session.

Tests: unit tests for the store; the perf spec measures channel-list calls on a second login (a budget, #287).

Approved for 0.7 (D-063). Follows up a note on #243. The first time a channel's newest texts are grouped into threads (#242, step 1a), each text is walked up to its thread's root. That costs one server call per text in a chain. `Kom::thread_root` remembers roots within a session, but they are lost on reload. **Keep text → root on the device:** - in IndexedDB in the browser and in a file on the desktop, like the search index (#239/#267); - per server and person; - with a size cap, dropping the least recently used entries; - dropped when the server says the text is gone. That makes the walk once per device instead of once per session. Tests: unit tests for the store; the perf spec measures channel-list calls on a second login (a budget, #287).

littlefox added this to the 0.7: Threads milestone

2026-10-22 14:41:29 +00:00

littlefox added the

area/reading

kind/feature

labels

2026-10-22 14:41:29 +00:00

littlefox referenced this issue

2026-10-22 14:41:47 +00:00

Channels as lists of threads, threads as chats (Teams-style) #242

littlefox commented

2026-10-23 00:43:57 +00:00

Author

Owner

Before building this I looked at what it would save now, after #284/#285, and it's less than the issue assumed. Flagging it rather than building it as written.

What a thread list costs on a second login, per card:

Walk up from the channel's newest text to its thread's root (topic_root). This is what #288 would keep on the device. Since #285 it fetches the 64 texts before it in the channel at once, so a 3 000-long chain costs a few dozen round trips, not 3 000.
Walk down the whole thread to build its index (thread_info: reply count, latest posts, participants, unread). Batched (16 at a time), but every text's stat, and its first line for split-offs (#284). This is the bigger part, and #288 as written doesn't touch it: the index lives for the session.

So keeping roots alone would save step 1 only, which is already cheap. Measured on the seeded 3 000-long Jättetråd: the list card appears in ~8 s locally; almost all of that is step 2.

Options:

A. Keep the thread index on the device (per server and person, like the search index): the root, counts, latest texts, participants, months, and each text's recipients/local numbers for unread. It's kept current within a session from new-text messages already; across sessions it would be refreshed by walking only the texts newer than what was stored (the channel's local numbers tell which). That's what would make a second login fast. Bigger: maybe 30–60 bytes per text, so a 3 000-text thread is ~150 kB.
B. Build #288 as written (roots only): small, but little gain now.
C. Drop #288 from 0.7 and revisit with #287's budgets: if "channel list at second login" doesn't miss its budget, nothing needs doing.

My recommendation: C now, and A if the budget says so. Labelled needs/user; I'm going on with #287 meanwhile.

Before building this I looked at what it would save now, after #284/#285, and it's less than the issue assumed. Flagging it rather than building it as written. **What a thread list costs on a second login, per card:** 1. *Walk up* from the channel's newest text to its thread's root (`topic_root`). This is what #288 would keep on the device. Since #285 it fetches the 64 texts before it in the channel at once, so a 3 000-long chain costs a few dozen round trips, not 3 000. 2. *Walk down* the whole thread to build its index (`thread_info`: reply count, latest posts, participants, unread). Batched (16 at a time), but every text's stat, and its first line for split-offs (#284). This is the bigger part, and #288 as written doesn't touch it: the index lives for the session. So keeping roots alone would save step 1 only, which is already cheap. Measured on the seeded 3 000-long Jättetråd: the list card appears in ~8 s locally; almost all of that is step 2. **Options:** - **A. Keep the thread index on the device** (per server and person, like the search index): the root, counts, latest texts, participants, months, and each text's recipients/local numbers for unread. It's kept current within a session from new-text messages already; across sessions it would be refreshed by walking only the texts newer than what was stored (the channel's local numbers tell which). That's what would make a second login fast. Bigger: maybe 30–60 bytes per text, so a 3 000-text thread is ~150 kB. - **B. Build #288 as written** (roots only): small, but little gain now. - **C. Drop #288** from 0.7 and revisit with #287's budgets: if "channel list at second login" doesn't miss its budget, nothing needs doing. My recommendation: **C now**, and A if the budget says so. Labelled `needs/user`; I'm going on with #287 meanwhile.

littlefox added the

needs/user

label

2026-10-23 00:44:01 +00:00

littlefox commented

2026-10-23 07:39:15 +00:00

Author

Owner

Dropped by the user (D-064), 2026-10-23: "Alrigt, then drop #288". Since #285 and #305 the walk up to a thread's root fetches the texts before it at once (a few dozen round trips for a 3 000-long chain), so keeping roots on the device would save a second or two. What costs time is reading the thread down for its index, which #288 didn't cover. The perf budgets (#287) will show if a second login or the thread lists get slow; then keeping the thread index on the device is the thing to do.