@ethora/chat-component-rn 26.7.8 → 26.7.10

package/src/components/styled/UnsupportedType.tsx

@@ -18,6 +18,7 @@ import { ActivityIndicator, View } from 'react-native';
 import { useChatSettingState } from '../../hooks/useChatSettingState';
 import { FileIcon } from '../../assets/icons';
 import { getExtensionForMime } from '../../helpers/mimeToExtension';
+import { getDisplayFileName } from '../../helpers/getDisplayFileName';
 
 interface FileDownloadProps {
   fileName: string;
@@ -47,6 +48,15 @@ const FileDownload: React.FC<FileDownloadProps> = ({
   const dispatch = useDispatch();
   const { config } = useChatSettingState();
 
+  // Bug #40: prefer the sender's original name over the server's stored
+  // hash name for both the visible label and the extension badge below.
+  const displayName = getDisplayFileName({
+    originalName,
+    fileName,
+    location: fileURL,
+    mimetype,
+  });
+
   const formatFileSize = (sizeInBytes: string): string => {
     const size = parseInt(sizeInBytes, 10);
 
@@ -101,9 +111,9 @@ const FileDownload: React.FC<FileDownloadProps> = ({
   };
 
   const extensionLabel = (() => {
-    const dotIndex = fileName.lastIndexOf('.');
-    if (dotIndex !== -1 && dotIndex < fileName.length - 1) {
-      return fileName.slice(dotIndex + 1).toUpperCase();
+    const dotIndex = displayName.lastIndexOf('.');
+    if (dotIndex !== -1 && dotIndex < displayName.length - 1) {
+      return displayName.slice(dotIndex + 1).toUpperCase();
     }
     return getExtensionForMime(mimetype).replace('.', '').toUpperCase();
   })();
@@ -123,7 +133,7 @@ const FileDownload: React.FC<FileDownloadProps> = ({
           isUser={isUser}
           colorIsUser={config?.colors?.primary}
           colorUsers={config?.colors?.secondary}
-        >{formatFileName(fileName, 20)}</FileName>
+        >{formatFileName(displayName, 20)}</FileName>
         {(pending || size) && (
           <FileSizeContainer>
             {pending ? (

package/src/components/styled/VideoMessage.tsx

@@ -19,6 +19,12 @@ import {
 
 interface CustomMessageVideoProps {
   fileName: string;
+  /**
+   * The sender's original file name (bug #40) - kept alongside `fileName`
+   * so the preview modal's save/share/download logic can prefer it over
+   * the server's stored/hashed name.
+   */
+  originalName?: string;
   fileURL: string;
   mimetype: string;
   /** The backend-generated poster frame (message.locationPreview). */
@@ -126,6 +132,7 @@ const PlaceholderVideo: React.FC<{
 
 const CustomMessageVideo: React.FC<CustomMessageVideoProps> = ({
   fileName,
+  originalName,
   fileURL,
   mimetype,
   previewURL,
@@ -134,7 +141,7 @@ const CustomMessageVideo: React.FC<CustomMessageVideoProps> = ({
   const [posterFailed, setPosterFailed] = useState(false);
 
   const handleOpen = () => {
-    dispatch(setActiveFile({ fileName, fileURL, mimetype }));
+    dispatch(setActiveFile({ fileName, fileURL, mimetype, originalName }));
     dispatch(setActiveModal(MODAL_TYPES.FILE_PREVIEW));
   };
 

package/src/context/xmppProvider.tsx

@@ -46,9 +46,12 @@ import {
   clearVisibleRoom,
   setLastViewedTimestamp,
   deleteRoomMessage,
-  msgSortableMs,
   setUnreadSyncing,
 } from '../roomStore/roomsSlice';
+import {
+  getFlushBoundaryTs,
+  getReadMarkerTimestamp,
+} from '../helpers/getServerReadTimestamp';
 import { runHistoryPreloadScheduler } from '../helpers/historyPreloadScheduler';
 import { updateMessagesTillLast } from '../helpers/updateMessagesTillLast';
 import { secureUserStorage } from '../helpers/secureUserStorage';
@@ -638,16 +641,43 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
       // Mark the open room "not visible" while backgrounded so messages
       // that arrive (or MAM-replay on reconnect) count as unread instead
       // of being silently treated as read — the "mounted == visible ==
-      // read" gap. Stamp lastViewed=now as the read baseline, clear
-      // visibility, then flush that marker to the server private store.
-      // Restored on the next 'active' transition above. Handled here in
-      // the provider so consumers using the component as a package get
-      // correct unread without reaching into the chat store themselves.
+      // read" gap. Stamp lastViewed=<the read boundary, if the user left
+      // scrolled up, else the newest server-acked message>, not
+      // Date.now(), as the read baseline: a device clock running ahead
+      // would otherwise write a future marker that the forward-only
+      // private-store merge can never correct again (bug #38). Then
+      // clear visibility and flush that marker to the server private
+      // store. Restored on the next 'active' transition above. Handled
+      // here in the provider so consumers using the component as a
+      // package get correct unread without reaching into the chat store
+      // themselves.
+      //
+      // The read boundary (rooms.readBoundaries) is deliberately left
+      // untouched here - MessageList normally stays mounted through a
+      // simple background/foreground cycle, so its own scroll-tracking
+      // ref (the only thing that could re-derive this value) is still
+      // intact, and clearing the redux copy would desync the two. It's
+      // only USED here for the one-shot stamp+flush, matching customer
+      // #42: leaving (or backgrounding) a room while scrolled up must not
+      // mark messages the user never reached as read.
       visibleBeforeBackground = visibleRoomJID;
+      let boundaryTs: number | null = null;
       if (visibleRoomJID) {
-        store.dispatch(
-          setLastViewedTimestamp({ chatJID: visibleRoomJID, timestamp: Date.now() })
+        boundaryTs = state.rooms?.readBoundaries?.[visibleRoomJID] ?? null;
+        const readTs = getReadMarkerTimestamp(
+          rooms?.[visibleRoomJID],
+          state.roomHeapSlice,
+          boundaryTs
         );
+        // Nothing to anchor to yet (no known messages, no prior marker)
+        // - skip the local stamp rather than fall back to the device
+        // clock. The flush below still runs so the visibility clear
+        // isn't blocked on this.
+        if (readTs > 0) {
+          store.dispatch(
+            setLastViewedTimestamp({ chatJID: visibleRoomJID, timestamp: readTs })
+          );
+        }
         // Drop the "New messages" divider for the room we're leaving so it
         // doesn't linger when the user comes back (mirrors ChatRoom's
         // unmount cleanup, which never runs while the pane stays mounted).
@@ -657,10 +687,21 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
         store.dispatch(clearVisibleRoom());
       }
       // Fire-and-forget — we're going to the background and don't
-      // care about the resolution path.
-      c.flushLastViewedToPrivateStoreStanza(rooms, { visibleRoomJID }).catch(
-        () => {}
-      );
+      // care about the resolution path. `visibleRoomTs` carries the same
+      // boundary to the SERVER marker - without it the flush defaults to
+      // "everything" for the visible room, overriding a correct smaller
+      // local count.
+      c.flushLastViewedToPrivateStoreStanza(rooms, {
+        visibleRoomJID,
+        // Clamped through the same helper as the local stamp above.
+        visibleRoomTs: visibleRoomJID
+          ? getFlushBoundaryTs(
+              rooms?.[visibleRoomJID],
+              state.roomHeapSlice,
+              boundaryTs
+            )
+          : undefined,
+      }).catch(() => {});
     });
     return () => sub.remove();
   }, [client, config?.xmppSettings?.keepAliveInBackground]);
@@ -672,11 +713,11 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
   // "shown" from "hidden", so the unread middleware would keep the open
   // room's badge at 0 and messages arriving while you're elsewhere look
   // already-read. When the host passes `isVisible`, mirror the AppState
-  // background/foreground handling: hidden → stamp lastViewed=now + clear
-  // room visibility (so later messages count) + flush; shown → restore
-  // visibility for the open room. Doing it here means consumers never
-  // touch the chat store themselves. (Undefined = host unmounts on hide,
-  // nothing to do.)
+  // background/foreground handling: hidden → stamp lastViewed=<newest
+  // server-acked message> + clear room visibility (so later messages
+  // count) + flush; shown → restore visibility for the open room. Doing
+  // it here means consumers never touch the chat store themselves.
+  // (Undefined = host unmounts on hide, nothing to do.)
   // -----------------------------------------------------------
   const chatWasVisibleRef = useRef(false);
   useEffect(() => {
@@ -691,10 +732,30 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
         store.dispatch(setVisibleRoom({ roomJID: activeRoomJID }));
       }
     } else {
+      // The read boundary (rooms.readBoundaries) is USED for the stamp
+      // and flush below but deliberately left in place - a host using
+      // `isVisible` keeps <Chat> mounted while hidden, so MessageList's
+      // own scroll-tracking ref is still intact and the redux copy must
+      // stay in sync with it. Only consumed, never Date.now(): a fast
+      // device clock would write a future marker that the forward-only
+      // private-store merge could then never correct (bug #38). And
+      // never "the newest acked message" unconditionally either - that
+      // silently marks messages the user scrolled past and never reached
+      // as read (bug #42, a regression of #33).
+      const boundaryTs = activeRoomJID
+        ? state.rooms?.readBoundaries?.[activeRoomJID] ?? null
+        : null;
       if (wasVisible && activeRoomJID) {
-        store.dispatch(
-          setLastViewedTimestamp({ chatJID: activeRoomJID, timestamp: Date.now() })
+        const readTs = getReadMarkerTimestamp(
+          rooms?.[activeRoomJID],
+          state.roomHeapSlice,
+          boundaryTs
         );
+        if (readTs > 0) {
+          store.dispatch(
+            setLastViewedTimestamp({ chatJID: activeRoomJID, timestamp: readTs })
+          );
+        }
         // Drop the "New messages" divider so it's gone when the user
         // returns to the chat (mirrors ChatRoom's unmount cleanup).
         store.dispatch(
@@ -705,7 +766,19 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
       store.dispatch(clearVisibleRoom());
       if (wasVisible && client?.flushLastViewedToPrivateStoreStanza) {
         client
-          .flushLastViewedToPrivateStoreStanza(rooms, { visibleRoomJID: activeRoomJID })
+          .flushLastViewedToPrivateStoreStanza(rooms, {
+            visibleRoomJID: activeRoomJID,
+            // Carry the same boundary to the SERVER marker - without it
+            // the flush defaults to "everything" for the visible room.
+            // Clamped exactly like the local stamp above.
+            visibleRoomTs: activeRoomJID
+              ? getFlushBoundaryTs(
+                  rooms?.[activeRoomJID],
+                  state.roomHeapSlice,
+                  boundaryTs
+                )
+              : undefined,
+          })
           .catch(() => {});
       }
     }
@@ -726,26 +799,45 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
       if (room.messages === lastMessagesRef) {return;}
       lastMessagesRef = room.messages;
 
-      let newest = 0;
-      const list = room.messages || [];
-      for (const m of list) {
-        if (!m || m.id === 'delimiter-new') {continue;}
-        const ms = msgSortableMs(m);
-        if (ms > newest) {newest = ms;}
-      }
-      if (newest <= lastStampedMs) {return;}
+      // getReadMarkerTimestamp (not a hand-rolled scan + Date.now()):
+      // it excludes pending/optimistic messages, which carry the DEVICE
+      // send time via `date` until the server echoes them back - a
+      // manual scan without that exclusion could pick up a pending
+      // message's device timestamp here and write a future marker the
+      // same way a raw Date.now() would (bug #38). And when the user has
+      // scrolled up (a boundary is set for this room), it clamps to that
+      // boundary instead of the newest message - without this, every
+      // incoming message while scrolled up advanced the marker to
+      // "newest" regardless of scroll position, and the later, smaller
+      // boundary write on leave was rejected by the forward-only
+      // private-store merge, leaving 0 unread even after a restart
+      // (customer #42, a regression of #33 reintroduced by #38).
+      const boundaryTs = s.rooms?.readBoundaries?.[jid] ?? null;
+      const newest = getReadMarkerTimestamp(room, s.roomHeapSlice, boundaryTs);
+      if (!newest || newest <= lastStampedMs) {return;}
       lastStampedMs = newest;
 
       store.dispatch(
-        setLastViewedTimestamp({ chatJID: jid, timestamp: Date.now() })
+        setLastViewedTimestamp({ chatJID: jid, timestamp: newest })
       );
 
       if (flushTimer) {clearTimeout(flushTimer);}
       if (client?.flushLastViewedToPrivateStoreStanza) {
         flushTimer = setTimeout(() => {
+          // Re-read fresh state rather than closing over `boundaryTs`:
+          // the user may have scrolled back to the bottom (clearing the
+          // boundary) in the 2s between the stamp and this flush, and
+          // the flush should reflect that.
+          const freshState = store.getState();
+          const freshBoundaryTs = freshState.rooms?.readBoundaries?.[jid] ?? null;
           client
-            .flushLastViewedToPrivateStoreStanza(store.getState().rooms?.rooms, {
+            .flushLastViewedToPrivateStoreStanza(freshState.rooms?.rooms, {
               visibleRoomJID: jid,
+              visibleRoomTs: getFlushBoundaryTs(
+                freshState.rooms?.rooms?.[jid],
+                freshState.roomHeapSlice,
+                freshBoundaryTs
+              ),
             })
             .catch(() => {});
         }, 2000);

package/src/helpers/createMessageFromXml.ts

@@ -93,6 +93,25 @@ export const createMessageFromXml = async (
   const senderLocal = senderJID.includes('@')
     ? senderJID.split('@')[0]
     : senderJID;
+
+  // Bug #41 root cause: the resource of the MUC `from` (room@conference/
+  // occupant-id) is the SAME field getDataFromXml uses to derive
+  // `user.id` for live messages and for the wrapped MAM convention
+  // (getHistory.xmpp.ts) - it's stamped by the server itself when the
+  // sender joined the room, so it's always present and always correct.
+  // The positional convention (onMessageHistory's MAM catch-up path)
+  // never called getDataFromXml, so it fell back to splitting the
+  // sender-supplied `<data senderJID>` attr on '@' instead - usually the
+  // same value, but WRONG (picks up the room's own id, not the
+  // sender's) whenever senderJID is absent from the stanza, and simply a
+  // different derivation than the live path even when it happens to
+  // agree. Prefer the resource-of-`from` here too so every path that
+  // reaches this function resolves the same sender identity the same
+  // way, instead of MAM catch-up rows needing a later correction once
+  // the "official" fetch lands.
+  const xmppFrom = (merged.xmppFrom || '').toString();
+  const fromResource = xmppFrom.includes('/') ? xmppFrom.split('/')[1] : '';
+
   const composed = [firstName, lastName].filter(Boolean).join(' ').trim();
   const existingName = String(merged?.user?.name || '').trim();
   const resolvedName =
@@ -107,7 +126,7 @@ export const createMessageFromXml = async (
     ...merged,
     user: {
       ...(merged.user || {}),
-      id: merged?.user?.id || senderLocal,
+      id: merged?.user?.id || fromResource || senderLocal,
       name: resolvedName,
       firstName: firstName || merged?.user?.firstName,
       lastName: lastName || merged?.user?.lastName,

package/src/helpers/getDisplayFileName.ts

@@ -0,0 +1,87 @@
+import { ensureFilenameHasExtension, filenameFromUrl } from './mimeToExtension';
+
+export interface DisplayFileNameOptions {
+  originalName?: string | null;
+  fileName?: string | null;
+  location?: string | null;
+  mimetype?: string | null;
+}
+
+/**
+ * Picks the best human-readable filename for a chat attachment - the
+ * single source of truth for every place a file name is rendered in the
+ * UI, saved to disk, shared, or downloaded.
+ *
+ * Priority: `originalName` (the sender's own file name, e.g. "test1.pdf")
+ * beats `fileName` (the server's stored/hashed name, e.g.
+ * "3f9a1c...c2.pdf") beats the last path segment of `location`. The
+ * stored hash name is only a fallback of last resort.
+ *
+ * Bug #40: display and save/share/download logic used to prefer the
+ * stored hash name over the original one, so an attachment sent as
+ * "test1.pdf" showed up (and got saved to the phone) as something like
+ * "3f9a1c...c2.pdf" - both directions (web -> RN and RN -> RN).
+ *
+ * Always returns a non-empty string with a valid extension: if the
+ * chosen candidate has no extension (a hash name can be `<hex>` with no
+ * extension at all, or `<hex>.<ext>`), one is appended from `mimetype`
+ * (or `.bin` as a last resort when the mime is unknown/missing too).
+ */
+export function getDisplayFileName(options: DisplayFileNameOptions): string {
+  const candidate =
+    (options.originalName && options.originalName.trim()) ||
+    (options.fileName && options.fileName.trim()) ||
+    filenameFromUrl(options.location) ||
+    '';
+  return ensureFilenameHasExtension(candidate, options.mimetype);
+}
+
+/**
+ * Makes a display name safe to use as an actual path segment when
+ * saving/sharing a file to the device: strips path separators (so an
+ * odd/hostile server-provided name can't escape the target directory)
+ * and control characters. Keeps the rest of the name - including the
+ * extension - intact.
+ */
+export function sanitizeFileNameForPath(name: string): string {
+  const cleaned = (name || '')
+    .replace(/[\/\\]/g, '_')
+    // eslint-disable-next-line no-control-regex
+    .replace(/[\x00-\x1f\x7f]/g, '')
+    .trim();
+  return cleaned || 'file';
+}
+
+/**
+ * Resolves a filename that is safe to write into a target directory:
+ * sanitizes it, then - if `exists` reports a collision - inserts
+ * " (1)", " (2)", ... before the extension until a free name is found,
+ * so saving two different attachments that share a display name never
+ * silently overwrites the first one.
+ *
+ * `exists` is injected so callers can back it with whatever existence
+ * check makes sense for their storage API (expo-file-system,
+ * StorageAccessFramework directory listing, ...) - this function stays
+ * pure and easy to unit test.
+ */
+export async function getUniqueFileName(
+  name: string,
+  exists: (candidateName: string) => Promise<boolean>
+): Promise<string> {
+  const safeName = sanitizeFileNameForPath(name);
+  if (!(await exists(safeName))) {
+    return safeName;
+  }
+  const dotIndex = safeName.lastIndexOf('.');
+  const base = dotIndex > 0 ? safeName.slice(0, dotIndex) : safeName;
+  const ext = dotIndex > 0 ? safeName.slice(dotIndex) : '';
+  // 999 collisions is already a pathological case; fall back to a
+  // timestamp suffix rather than looping forever.
+  for (let i = 1; i < 1000; i += 1) {
+    const candidate = `${base} (${i})${ext}`;
+    if (!(await exists(candidate))) {
+      return candidate;
+    }
+  }
+  return `${base} (${Date.now()})${ext}`;
+}

package/src/helpers/getServerReadTimestamp.ts

@@ -0,0 +1,197 @@
+import type { IMessage, IRoom } from '../types/types';
+import { msgSortableMs } from './msgSortableMs';
+
+// A stored/stamped read marker more than this far past the newest
+// message we actually know about for a room is not "the user is a
+// little ahead" - it's a leftover from a device whose clock was wrong
+// when it stamped the marker (bug #38). Generous on purpose: this value
+// only controls when we're willing to treat an existing marker as
+// corrupt and self-heal it, never how far off a legitimate new write can
+// be, so a false positive here just means a bad value survives one extra
+// cycle, not that a good value gets rejected.
+export const FUTURE_READ_MARKER_TOLERANCE_MS = 5 * 60 * 1000;
+
+export interface ReadTimestampHeapState {
+  messageHeap?: IMessage[] | null;
+  failedMessages?: Record<string, unknown> | null;
+}
+
+type RoomForReadTimestamp = Pick<IRoom, 'jid' | 'messages' | 'lastViewedTimestamp'>;
+
+/**
+ * Resolve the "read up to here" marker for `room` using SERVER time,
+ * never the device clock.
+ *
+ * Bug #38: if the device clock is ahead when the user leaves a room, a
+ * `Date.now()` read marker lands in the future. The private-store merge
+ * (flushLastViewedToPrivateStore.ts) is forward-only ("if (prevNum >=
+ * ts) continue"), so once a future marker is written, no later
+ * *correct* write can ever replace it - the room's unread count is
+ * stuck wrong forever, on every device, from that point on. Anchoring
+ * to the newest SERVER-acknowledged message's own timestamp instead
+ * means the marker we write can never be ahead of what the server
+ * itself has recorded for the room.
+ *
+ * "Server-acknowledged" excludes:
+ *  - a message still marked `pending` (the optimistic bubble shown
+ *    while a send is in flight - it carries the DEVICE send time via
+ *    `date`, not a server timestamp, until the server echoes it back
+ *    and insertMessageWithDelimiter flips `pending` off);
+ *  - a message id present in `heapState.messageHeap` (queued retry -
+ *    used for offline media sends, see roomHeapSlice.ts) or
+ *    `heapState.failedMessages` (a send that never reached the server
+ *    at all).
+ *
+ * `msgSortableMs` (helpers/msgSortableMs.ts) reads the server-assigned microsecond
+ * timestamp encoded in the first 13 digits of the message id - the same
+ * source already used for message ordering and unread counting - so
+ * this stays consistent with the rest of the read/unread pipeline.
+ *
+ * Falls back to the room's existing `lastViewedTimestamp` (so leaving
+ * an empty or never-scrolled room doesn't regress the marker), then to
+ * `0` when there's truly nothing to anchor to yet (a brand new room
+ * with no history and no prior marker). Callers should treat `0` as
+ * "skip the write" rather than substituting a device-clock guess.
+ */
+export function getServerReadTimestamp(
+  room: RoomForReadTimestamp | null | undefined,
+  heapState?: ReadTimestampHeapState | null
+): number {
+  if (!room) {return 0;}
+
+  const heapIds = new Set(
+    (heapState?.messageHeap || [])
+      .filter((m) => m && m.id != null)
+      .map((m) => String(m.id))
+  );
+  const failedIds = new Set(Object.keys(heapState?.failedMessages || {}));
+
+  let newest = 0;
+  const messages = room.messages || [];
+  for (const m of messages) {
+    if (!m || !m.id) {continue;}
+    const id = String(m.id);
+    if (id === 'delimiter-new' || id === 'delimiter-new-local') {continue;}
+    if ((m as any).pending) {continue;}
+    if (heapIds.has(id) || failedIds.has(id)) {continue;}
+
+    const ts = msgSortableMs(m);
+    if (ts > newest) {newest = ts;}
+  }
+
+  if (newest > 0) {return newest;}
+  if (room.lastViewedTimestamp && room.lastViewedTimestamp > 0) {
+    return room.lastViewedTimestamp;
+  }
+  return 0;
+}
+
+/**
+ * Is `marker` a leftover from a device whose clock was wrong when it
+ * stamped a read marker (bug #38)?
+ *
+ * TWO independent signals must agree before we're willing to throw a
+ * stored marker away, because "waive the forward-only guard" is a
+ * destructive operation:
+ *
+ *  1. it sits well past the newest message we know the room has, AND
+ *  2. it sits well past real time.
+ *
+ * Signal 1 alone is NOT enough, and that is the whole point of this
+ * function: a device whose local cache for a room is simply stale (very
+ * common - any room whose history hasn't been synced yet this session)
+ * sees a perfectly legitimate marker written by another device that HAS
+ * seen newer messages, and would happily "heal" it backwards, resurrecting
+ * already-read messages as unread on every device. A real timestamp can
+ * never be ahead of real time, so requiring signal 2 as well means a
+ * stale cache on its own can no longer trigger the self-heal.
+ *
+ * Signal 2 alone is not used either: it would let a device whose own
+ * clock is running SLOW mistake every correct marker for a corrupt one.
+ */
+export function isCorruptFutureReadMarker(
+  marker: number,
+  newestAckedMs: number
+): boolean {
+  if (!Number.isFinite(marker) || marker <= 0) {return false;}
+  if (!(newestAckedMs > 0)) {return false;}
+  if (marker <= newestAckedMs + FUTURE_READ_MARKER_TOLERANCE_MS) {return false;}
+  return marker > Date.now() + FUTURE_READ_MARKER_TOLERANCE_MS;
+}
+
+/**
+ * Resolve the marker to STAMP (locally and to the server) for `room`,
+ * honouring an explicit read boundary when one is set.
+ *
+ * Bug #42 (a regression of #33, reintroduced by #38): #38 made every
+ * caller stamp the newest server-acknowledged message unconditionally.
+ * That is correct for a user who is at the bottom of the room, but wrong
+ * for a user who scrolled up, received messages, and left without
+ * scrolling back down - stamping "newest" there silently marks
+ * messages they never saw as read, both locally and (because the
+ * private-store merge is forward-only) permanently on the server.
+ *
+ * `boundaryTs` is the msgSortableMs of the newest message the user
+ * actually reached (see `readBoundaries` on `RoomMessagesState`,
+ * populated by MessageList's `onReadBoundaryChange`). When it's set and
+ * positive, it wins - but is still clamped to never exceed the newest
+ * server-acknowledged message, so a stale/corrupt boundary can't stamp a
+ * marker further ahead than the room's own history supports. When no
+ * boundary is set (the common case - the user is at the bottom), this is
+ * exactly `getServerReadTimestamp`.
+ *
+ * Never returns `Date.now()`, directly or indirectly - same rule as
+ * `getServerReadTimestamp` (bug #38).
+ */
+export function getReadMarkerTimestamp(
+  room: RoomForReadTimestamp | null | undefined,
+  heapState?: ReadTimestampHeapState | null,
+  boundaryTs?: number | null
+): number {
+  const newestAcked = getServerReadTimestamp(room, heapState);
+  if (
+    typeof boundaryTs === 'number' &&
+    Number.isFinite(boundaryTs) &&
+    boundaryTs > 0
+  ) {
+    // `newestAcked === 0` means this room has NOTHING server-acked and no
+    // prior marker, so there is nothing to clamp the boundary against -
+    // and MessageList derives the boundary from the rendered list, which
+    // at that point can only contain pending/failed sends carrying the
+    // DEVICE clock via `date`. Returning it here would smuggle a
+    // device-clock marker back in through the boundary (bug #38). Return
+    // 0 = "nothing to anchor to, skip the write", same contract as
+    // getServerReadTimestamp.
+    return newestAcked > 0 ? Math.min(boundaryTs, newestAcked) : 0;
+  }
+  return newestAcked;
+}
+
+/**
+ * The value to hand `flushLastViewedToPrivateStore` as `visibleRoomTs`
+ * for a room being left, or `undefined` when no boundary applies (the
+ * flush then uses its own newest-acked default).
+ *
+ * Exists so the SERVER write goes through the SAME clamp as the local
+ * stamp. Passing the raw redux boundary straight through would bypass
+ * `getReadMarkerTimestamp`'s clamp on exactly the path where a bad value
+ * is permanent: the private-store merge is forward-only, so a boundary
+ * that (through a pending own message's device `date`, or a stale
+ * readBoundaries entry) sat ahead of the room's real history would be
+ * written verbatim and could never be corrected again (bug #38).
+ */
+export function getFlushBoundaryTs(
+  room: RoomForReadTimestamp | null | undefined,
+  heapState?: ReadTimestampHeapState | null,
+  boundaryTs?: number | null
+): number | undefined {
+  if (
+    typeof boundaryTs !== 'number' ||
+    !Number.isFinite(boundaryTs) ||
+    boundaryTs <= 0
+  ) {
+    return undefined;
+  }
+  const clamped = getReadMarkerTimestamp(room, heapState, boundaryTs);
+  return clamped > 0 ? clamped : undefined;
+}

package/src/helpers/initXmppRooms.tsx

@@ -1,5 +1,4 @@
 import { setCurrentRoom, setIsLoading } from '../roomStore/roomsSlice';
-import { updatedChatLastTimestamps } from './updatedChatLastTimestamps';
 import { initRoomsPresence } from './initRoomsPresence';
 import XmppClient from '../networking/xmppClient';
 import { IConfig, IRoom, User } from '../types/types';
@@ -48,15 +47,16 @@ const initXmppRooms = async (
         console.log(res);
       }
 
-      //@ts-ignore
-      const roomTimestampObject: [jid: string, timestamp: string] =
-        await (xmmpClient as any as XmppClient).getChatsPrivateStoreRequestStanza();
-      updatedChatLastTimestamps(roomTimestampObject, store.dispatch);
+      // getChatsPrivateStoreRequestStanza hydrates redux itself
+      // (dispatch(applyPrivateStoreMarkers(...)) internally, clamped +
+      // forward-only) - do not also apply the raw return value here. That
+      // used to double-dispatch via updatedChatLastTimestamps' unconditional
+      // setLastViewedTimestamp, which has neither the forward-only guard
+      // nor the future-marker clamp, so it could silently re-clobber a
+      // value the clamp had just corrected (bug #38).
+      await (xmmpClient as any as XmppClient).getChatsPrivateStoreRequestStanza();
     } else {
-      //@ts-ignore
-      const roomTimestampObject: [jid: string, timestamp: string] =
-        await xmmpClient.getChatsPrivateStoreRequestStanza();
-      updatedChatLastTimestamps(roomTimestampObject, store.dispatch);
+      await xmmpClient.getChatsPrivateStoreRequestStanza();
     }
 
     if (config?.refreshTokens?.enabled) {