Chathistory seeding and scroll back paging by Jokler · Pull Request #131 · hivecom/orbit

Jokler · 2026-07-21T16:37:46Z

This PR adds the history functionality:

HISTORY LATEST gets sent on channel JOIN
a new command is added to core-wasm which sends HISTORY BEFORE to enable scroll-back functionality
the labeled-response` capability is enabled to track which channel a batch belongs to (this should be used for all requests that expect a response from now on)
ResponseChannels now times out channels after 1-2 seconds of no reply from the server, this means buggy command implementations don't freeze and can be logged but should be adjusted later to not fail on high latency connections
a demo of working chat functionality which starts with 5 lines of history and a button to request 5 more

Resolves: #33

Notes:

after talking to @dolanske we made the decision to send back events in the on_event callback even if they are also returned by ResponseChannel until we notice any performance cost to it
the Actor is starting to get large, the actor.rs file contains types that can be moved out but we might want to think about creating an abstraction that allows functionality to be separated by topic
this PR does NOT implement Message buffer ordering and dedup #34

If no replies are sent there is no way to know which target a batch belongs to except for assuming that it's the next batch. Requested messages were reduced to 5 to simplify testing.

Other response channels should also use labels from now on if possible

zealsprince

The Tags::parse consolidation is a real improvement - the per-command tag loops were already drifting apart, and centralizing the msgid/server-time fallbacks into one place makes the JOIN/PART/QUIT handlers much easier to follow. The push_batch early-return pattern keeps the history plumbing out of the normal message flow nicely. Great work!

Three things I'd fix before merge: the unrequested-batch assert panic (actor.rs:475 - a multiline message from another client kills the connection), QUIT messages being typed as Part (actor.rs:445), and scrollback messages appending twice in the store (irc.ts:144).
Broader points that don't need to block:

The actor loop unwraps handle_incoming, so every assert in the handlers (batch id match, batch.channel equality in push_batch, server_time.is_some() on playback JOINs) is a connection-killer if a server misbehaves. Fine for the prototype, but once we're past labeled-response bring-up these should become warn-and-skip. Happy to make a ticket for that.
The is_chathistory checks after a push_batch early return (actor.rs:363, 381, 427, 463) can't be false anymore at those points - dropping them would make the flow clearer.
Preexisting, not this PR: the react/unreact branches look inverted (actor.rs:658 pushes the reactor on unreact and removes on react). Separate ticket?

I did notice some stray blank lines in core-shared/Cargo.toml (lines 2, 17), Tags::parse taking &Vec<Tag> over &[Tag], and channel_mut/user_mut/push_batch being async without awaiting anything; not a blocker but just for the sake of checking the diff I noticed these.

zealsprince · 2026-07-25T17:07:43Z

+      const existingServer = serverMessages.get(id) ?? new Map()
+      const existingChannel = existingServer.get(history.channel) ?? []
+
+      for (const message of history.messages) {


I think scrollback messages get appended twice: the on_data handler pushes them when the History event fires (line 99-110), and then this loop pushes the same history.messages from the resolved promise. The actor always does both - reply(...) and on_event(ServerEvent::History(...)) back to back in the BATCH close handler. Since we decided to dual-deliver on the Rust side, I think the store has to pick one path - probably let on_data own the appending and use the promise result just for "did it finish".

zealsprince · 2026-07-25T17:08:17Z

+
+  async function requestScrollback(id: number, channel: string) {
+    try {
+      const history = await serverHandlers.value.get(id)?.history_before(channel, serverMessages.get(id)?.get(channel)?.at(0)?.metadata.msgid ?? "")


First click before any history has landed sends msgid= with an empty id - does the server FAIL that, or silently treat it as *? Might be worth skipping the request (or falling back to LATEST) when there's no oldest message yet.

zealsprince · 2026-07-25T17:08:49Z

+    try {
+      const history = await serverHandlers.value.get(id)?.history_before(channel, serverMessages.get(id)?.get(channel)?.at(0)?.metadata.msgid ?? "")
+
+      if (!!!history) {


We really NOT NOT NOT want history? :)

zealsprince · 2026-07-25T17:10:47Z

        loop {
+            #[cfg(feature = "web")]
+            let mut timeout = gloo_timers::future::TimeoutFuture::new(1000).fuse();
+            #[cfg(not(feature = "web"))]


This is the cfg gate that my above comment references.

zealsprince · 2026-07-25T17:11:04Z

@@ -1,12 +1,21 @@
-use std::fmt;
+#[cfg(feature = "default")]


Gating this import on feature = "default" while the use site (line 275) is gated on not(feature = "web") means a build with default-features = false and no web fails to compile, and a build with both features gets an unused-import warning. Do we want a named feature like native instead of leaning on default as a cfg? Then both gates can agree.

zealsprince · 2026-07-25T17:15:46Z

+                if let Some(ref t) = message.tags {
+                    tags = Tags::parse(t);
+                }
+                assert_eq!(


I'm not 100% sure about this one and I paste this over into Claude to walk me through it in detail but from what I understand, this assert is a crash path for any batch we didn't request. The BATCH open handler returns early without setting current_batch when the label lookup fails (line 557-564), so the first PRIVMSG inside such a batch has a batch tag while current_batch is None, the assert fires, and the unwrap() in run() takes the whole actor down. We request draft/multiline (line 1046), so a multiline message from any other client is enough to trigger it. A labeled-response wrapper batch around the chathistory batch would hit the same thing via the nested inner batch.

zealsprince · 2026-07-25T17:16:37Z

+                    let Some(idx) = self
+                        .requested_batches
+                        .iter()
+                        .position(|b| b.label == tags.label)


Matching pending requests purely by label means that when labeled-response isn't enabled, any server-initiated unlabeled batch matches label == None and steals the pending history request, attributing its messages to the wrong channel. Should this also cross-check the channel from the batch param? Fine as a follow-up ticket if we're treating no-labeled-response servers as out of scope for now :)

zealsprince · 2026-07-25T17:17:09Z

-                            text: m.text.clone().map(|t| t.content)?,
-                            username: m.metadata.user.clone(),
-                        })
+                    .map(|m| MessageReference {


Behavior change worth confirming: a reply to a message we don't have now fabricates a MessageReference with "Unknown"/"Unknown", where before it produced no reference at all.

zealsprince · 2026-07-25T17:18:54Z

+            .unix_timestamp()
+    }
+
+    pub fn msgid_with_fallback(&self, hash_extras: &[&str]) -> String {


The fallback hash covers server_time plus the extras, but not the message type - a JOIN and PART from the same user in the same second (extras are just [source] for both) produce the same msgid and collide in channel.messages and in the Vue :key. Probably want to add the type to the hash. Only matters for servers that don't send msgid, so no rush since our server for testing does enable it.

Brings up the question if we should have a stupid traditional IRC server to test against.

zealsprince · 2026-07-25T17:19:17Z

+            .await
+            .context("Failed to send ActorMessage")?;
+
+        let resp = rx.await.context("Failed to await actor history message")?;


Jokler added 4 commits July 21, 2026 17:45

Core: Request history on channel join and create batched history event

0e8bc4f

Add untested history_before command

2078a99

Fix incomplete assert

f6ae112

Time out response channels after ~1s

1bee42f

Jokler linked an issue Jul 21, 2026 that may be closed by this pull request

Chathistory seeding and scroll-back paging #33

Open

Remove target requirment on CommandKey::History for now

078d804

If no replies are sent there is no way to know which target a batch belongs to except for assuming that it's the next batch. Requested messages were reduced to 5 to simplify testing.

Jokler added this to Orbit Jul 21, 2026

Jokler moved this to In progress in Orbit Jul 21, 2026

Jokler force-pushed the 33-chathistory-seeding-and-scroll-back-paging branch from 6603c6f to f8ec18c Compare July 24, 2026 13:35

Jokler added 4 commits July 24, 2026 15:40

Create a demo that connects to one channel and can request more history

5b7a302

Associate history batch by label

e33a9e0

Other response channels should also use labels from now on if possible

Rename ChannelRole::None to Regular to match standard IRC terms

545c5ff

Always track channel for requested chat history

bc8bf48

Jokler force-pushed the 33-chathistory-seeding-and-scroll-back-paging branch from f8ec18c to bc8bf48 Compare July 24, 2026 13:44

Jokler marked this pull request as ready for review July 24, 2026 13:56

Jokler requested a review from zealsprince July 24, 2026 13:56

Jokler moved this from In progress to In review in Orbit Jul 24, 2026

zealsprince requested changes Jul 25, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Chathistory seeding and scroll back paging#131

Chathistory seeding and scroll back paging#131
Jokler wants to merge 9 commits into
prototypefrom
33-chathistory-seeding-and-scroll-back-paging

Jokler commented Jul 21, 2026 •

edited

Loading

Uh oh!

zealsprince left a comment

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026 •

edited

Loading

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

zealsprince Jul 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Jokler commented Jul 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Notes:

Uh oh!

zealsprince left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

zealsprince Jul 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Jokler commented Jul 21, 2026 •

edited

Loading

zealsprince Jul 25, 2026 •

edited

Loading