eleven / ocho Public

web+native: Convert to thread — a chain that got long in the chat becomes a thread (#1493)

* web: Convert to thread — take a long inline reply chain out of the feed

Inline replies and threads are separate verbs, and every reply in the
history from before that split is inline: the only way a long chain
becomes a thread is after the fact. The messages can't be rewritten to
say so — only their author may edit one, only for fifteen minutes, and
rewriting N messages would churn N authorships and timestamps to change
a display rule — so a conversion is its own encrypted event, exactly as
a reaction is: an ordinary message carrying { type: "threadconvert",
root, ids } that every client folds client-side. The server stores one
more opaque blob and learns nothing; a client too old to know the type
drops it and goes on showing the chain inline.

The fold is a claim map (sid → { root, at }) projected onto the loaded
window as a `movedTo` stamp, which threadRootOf reads beside the wire
flag — so the tally, the transcript filter, the thread view, the ▤
Threads list and both compose verbs all work unchanged. The merge rule
is a pure function of the SET of events, never their arrival order: the
oldest conversion owns a message, a repeat is a no-op, a claim whose
root was itself converted flattens onto the outermost root (threads
never nest), and a cycle — which only a made-up payload can produce —
leaves everything inline.

The verb is offered only where there IS a chain to move (inlineChainIds,
the transitive quote walk back in the one narrow place that needs it —
on the converting client, at menu time, never as a membership rule), so
never on a message nobody answered and never inside a thread pane. It
confirms, because it reorganises the chat for everyone and v1 has no
undo.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* core+ios+mac: Convert to thread on native, and the shared fold

The native half of "Convert to thread" — same encrypted event, same fold
rules, pinned against the same vectors as the web.

ChatFeedModel gains the conversion state (a claim map: message id → the
thread it moved into, plus the convert event's own server id as the
tie-break) and its projection onto the loaded window (`movedTo`, which
threadRootID now reads beside the wire flag). One rollup seam —
refreshRollup — applies the conversions and re-derives the tallies, so
no fold path (history page, live frame, edit, delete, optimistic send)
can publish a list that forgot one. mainFeedItems now asks threadRootID
rather than re-checking the flag itself, which is what let a converted
message stay in the transcript.

Conversions reach the model three ways and settle identically: a live
"threadconvert" frame, a history page, and the local store (the NSE and
background sync park rows while the app is suspended) — so a cold open
shows a converted chain already in its thread instead of inline for the
moment before the network page re-folds it.

The verb rides MessageActions, so it appears in the iOS context menu,
the iOS long-press sheet and the Mac right-click NSMenu from one gate:
`hasInlineChain`, folded once per publish because the containers build a
menu for EVERY row on screen and the chain walk is O(list). The vectors
pin the flag as exactly `!inlineChainIDs(…).isEmpty`. It confirms
(ChatFeedModel.convertConfirm — one wording for all three platforms) and
is nil inside a thread view, where nothing inline hangs off a bubble.

The notification extension ships a conversion as a silent, passive entry
rather than "New message": nobody said anything. It still ingests the
row, so the app opens with the chain already tucked away. Older installed
builds have no such branch — they will show a plain banner for a
conversion until they update.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web+core: an unloaded converted root is named by nothing, never by the wrong message

threadTarget's paged-out-root fallback assumed the reply's frozen ref IS
the root's snapshot. That holds for a FLAGGED thread reply (every thread
send derives its ref from the root) but not for a converted one, whose
ref is whatever it quoted. So a thread whose root had scrolled out could
be headed — in the ▤ Threads list, and in the thread view — by the name
and text of a message that isn't its root.

Now the id travels alone in that case: the reply still lands in the
right thread, and the view says the original isn't available rather than
naming the wrong message. Flagged replies are unchanged.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web: keep Convert to thread out of the thread view's own menus

A thread's ROOT renders inside the thread view as its first message, and
it can still have inline replies out in the feed — so the chain under it
is genuinely non-empty and the verb was appearing on that one bubble.
Tidying feed replies is something you do while looking at the feed, so
the menus opened from inside a thread panel don't offer it. Matches what
the native containers already do (onConvertToThread = nil in the
pane/thread catalogues).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web: a converted reply's quote card opens the thread it advertises

Rendered inline (its root paged out), a converted reply's card wears the
same "N Replies" thread link a flagged one does — paintQuoteThreadLink
reads the same rollup — but tapping it jumped to the message it quoted,
because the open was gated on the wire flag rather than on threadRootOf.
So the card advertised a thread and didn't open it.

Now it asks the same question everything else asks, which is also the
question native already asked (MessageBubble's replyQuote →
threadRootID) — so this is the web catching up to the Mac and iOS.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* docs: map ICON_FOLD_IN in the icon table

Convert to thread's glyph, and which of its four surfaces actually wear
one (the web picker's rows are icon-only; the iOS context menu and the
Mac NSMenu are text by construction).

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web: comment accuracy — the iOS extension can't drop a push, it silences one

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* ios: title-case the Convert to Thread alert, matching its menu item

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* ios: hold the conversion's count so the confirm doesn't flash '0 replies' on dismiss

The alert's message is re-evaluated as it dismisses, by which time the
target is already nil.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web+core: a failed conversion says so, and the fold stops paying per message

Four findings from review, all real:

**A conversion that can't be sent was silent on both platforms.** Nothing
about a failed one is visible — the chain simply stays where it was,
which is exactly what it looks like when nobody converted anything — so
after confirming a one-way act the reader was left believing it
happened. convertToThread now reports (@discardableResult -> Bool
natively), and both surfaces say so inline: a private "only visible to
you" notice on web, the FeedNoteBar on Mac and iOS. Never a toast.

**The web re-resolved every claim once per folded message.** applyConverts
walks the whole claim map, and the chat.msg fold called it for every
arrival — so a hundred-row history page did a hundred full resolutions.
It now asks one O(1) question first (does a conversion name THIS sid?),
which is exact: a claim resolves against the claim map alone, never
against the loaded window, so an arrival can't change any other
message's stamp.

**Nothing bounded a conversion's id list.** The server caps a blob at
64KB and can't read it, so a hostile client could name thousands per
event into a map that is never pruned. Both folds take a generous slice
(2000 — far above any real chain), pinned by a test on each side.

**Two native paths, from the same review:** a live convert frame skipped
tamper-evidence gossip that the same event arriving in a history page
gets; and foldPage had grown to THREE decrypts per ordinary row (inside
the loop Perf watches at 250ms) — one now serves both event checks.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web: a Threads row whose root scrolled out says so, instead of a blank line

A converted chain has no truthful stand-in when its root is paged out
(only a flagged reply's ref is its root's own snapshot), so the row
rendered an empty line above its tally and read 'Open thread, 3 Replies,'
to a screen reader. It now says what the thread view says in the same
case.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

* web+core: a conversion moves a CHAIN, and web validates it the way Swift does

Three findings from independent review of #1493.

**Web coerced where Swift type-checks, so the two platforms folded the
same event differently.** MessagePayload types root/ids as Int64, so
`{root:"400", ids:["401","402"]}` fails to decode natively and the whole
payload is dropped — while web's `Number(x) || 0` performed a full
working conversion. Same messages, a different transcript per platform,
which the cross-platform contract calls a hard error. And `root: -1`
stamped movedTo=-1: a phantom tally, a nameless row in the ▤ Threads
list, and a "Reply in thread" that would persist a real message anchored
to an id that can never exist. Web now validates with Number.isSafeInteger
and mirrors Swift's guards (root/at > 0, each id > 0 and != root), whole
payload or single id.

**The tie-break wasn't pinned by any vector.** In
convert_overlapping_and_repeated both competing events name the SAME
root, so oldest-wins and newest-wins produce identical output — flipping
the rule failed 0 of 8 assertions. convert_conflicting_claims_oldest_wins
has two conversions disagree about the root, with roots in different
threads so the flatten can't mask it; flipping the rule now fails two
vector tests and a unit test.

**The shipped primitive was "move any N messages under any root".** A
receiver took the id list at face value, and a conversion renders no
bubble, the oldest claim wins forever, and deleting the convert row is
not an undo — so one crafted payload could quietly hide a couple of
hundred unrelated messages under an old root, unattributably. A claim
now holds only when the message's own quote is the root or another
claimed message, checked against the message itself on every client. It
stays order-independent and needs no loaded window: a claimed message
that hasn't arrived has no quote to check and stays inline until it
does, the same degradation as a thread reply whose root is paged out.

Also: the iOS confirm's count is now set in the same update as its
target (an onChange could not seed it before the alert's first render);
the chat-list line counts what the fold took, not what the payload asked
for; and the "threads don't nest" comment now says what is actually
guaranteed — claim-rooted nesting flattens, but a wire-flagged reply is
authoritative and can end up one level inside a converted thread if a
"Reply in thread" is in flight while someone converts the chain.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EXy6kzmYE9rChy3KgciJvZ
🤖 Generated with [Claude Code](https://claude.com/claude-code)

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>