@ethora/chat-component-rn 26.8.1 → 26.8.2

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/historyPreloadScheduler.ts

@@ -1,7 +1,11 @@
 import { AppState } from 'react-native';
 import XmppClient from '../networking/xmppClient';
 import { store } from '../roomStore';
-import { applyRoomsPreloadBatch, setUnreadSyncing } from '../roomStore/roomsSlice';
+import {
+  applyRoomsPreloadBatch,
+  setUnreadSyncing,
+  RUNTIME_MESSAGE_LIMIT,
+} from '../roomStore/roomsSlice';
 import { IMessage, IRoom } from '../types/types';
 
 interface HistoryPreloadSchedulerOptions {
@@ -30,6 +34,13 @@ const DEFAULT_CONCURRENCY = 3;
 // `mergeHistoryIntoCache` rarely has to fall back to clear-and-replace.
 const DEFAULT_PAGE_SIZE = 20;
 const DEFAULT_RETRY_LIMIT = 2;
+// When the first page is entirely unread (every fetched message is newer
+// than `lastViewedTimestamp`), the true unread count could be far bigger
+// than `pageSize` — `useUnread()` only ever sees what's been loaded. Page
+// further back, up to this many extra fetches, until we either find the
+// boundary or give up (`unreadCapped` then stays true so callers at least
+// know the count is a floor, not exact). Customer-reported #34.
+const MAX_UNREAD_CATCHUP_PAGES = 8;
 
 const sleep = (ms: number) => new Promise((resolve) => setTimeout(resolve, ms));
 
@@ -226,9 +237,75 @@ export const runHistoryPreloadScheduler = async (
             }
 
             const nextRoom = store.getState().rooms.rooms[item.jid];
+            let combined: IMessage[] = fetchedMessages || [];
+            const lastViewed = Number(nextRoom?.lastViewedTimestamp) || 0;
+
+            // The first page was entirely unread — keep paging older until
+            // we find a message at/before `lastViewedTimestamp` (the true
+            // boundary) or run out of catch-up budget, so the count isn't
+            // silently truncated at `pageSize`.
+            if (lastViewed > 0 && computeUnreadCapped(nextRoom, combined, pageSize)) {
+              let lastPageLen = combined.length;
+              let extraPages = 0;
+              while (
+                extraPages < MAX_UNREAD_CATCHUP_PAGES &&
+                lastPageLen >= pageSize &&
+                !signal?.aborted
+              ) {
+                const oldestId = combined.reduce<number | null>((min, m) => {
+                  const idNum = Number((m as any)?.id);
+                  if (!Number.isFinite(idNum)) {return min;}
+                  return min === null || idNum < min ? idNum : min;
+                }, null);
+                if (oldestId === null) {break;}
+
+                let older: IMessage[] | undefined;
+                try {
+                  older = await client.getHistoryStanza(
+                    item.jid,
+                    pageSize,
+                    oldestId,
+                    undefined,
+                    {
+                      coalesceRoom: true,
+                      skipIfPreloaded: !forceReload,
+                      source: 'background',
+                    }
+                  );
+                } catch {
+                  break;
+                }
+                if (!older || !older.length) {break;}
+
+                combined = [...older, ...combined];
+                lastPageLen = older.length;
+                extraPages++;
+
+                const oldestTs = combined.reduce<number>((minTs, m) => {
+                  const ts = messageTimestamp(m);
+                  return ts > 0 ? Math.min(minTs, ts) : minTs;
+                }, Number.MAX_SAFE_INTEGER);
+                if (oldestTs !== Number.MAX_SAFE_INTEGER && oldestTs <= lastViewed) {
+                  break;
+                }
+              }
+            }
+
+            // `mergeHistoryIntoCache` (roomsSlice) caps whatever we dispatch
+            // here to the newest RUNTIME_MESSAGE_LIMIT messages before it
+            // ever reaches `unreadMiddleware` — so a catch-up fetch that
+            // pulled the true boundary can still have it silently dropped
+            // by that cap, leaving a falsely-confident `unreadCapped:false`
+            // (bug #34's failure mode again, just one layer downstream).
+            // Simulate that cap here so the flag reflects what will
+            // actually survive, not just what this fetch retrieved.
+            const simulatedStored =
+              combined.length > RUNTIME_MESSAGE_LIMIT
+                ? combined.slice(-RUNTIME_MESSAGE_LIMIT)
+                : combined;
             const unreadCapped = computeUnreadCapped(
               nextRoom,
-              fetchedMessages || [],
+              simulatedStored,
               pageSize
             );
 
@@ -237,7 +314,7 @@ export const runHistoryPreloadScheduler = async (
                 rooms: [
                   {
                     jid: item.jid,
-                    messages: fetchedMessages || [],
+                    messages: combined,
                     unreadCapped,
                     historyPreloadState: 'done',
                   },

package/src/helpers/initXmppRooms.tsx

@@ -1,9 +1,9 @@
 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';
 import { store } from '../roomStore';
+import { refreshAuthTokensQuietly } from '../networking/authRefresh';
 
 const initXmppRooms = async (
   user: User,
@@ -47,19 +47,23 @@ 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) {
-      config?.refreshTokens?.refreshFunction?.();
+      // Was a bare call to the consumer-supplied refreshFunction, i.e. a
+      // rotation completely outside the SDK's lock. Routed through the
+      // one rotation point, which calls that same function internally.
+      refreshAuthTokensQuietly();
     }
   } catch (error) {
     console.error(error);

package/src/helpers/insertMessageWithDelimiter.ts

@@ -1,5 +1,35 @@
 import { IMessage } from '../types/types';
 import { isDateAfter, isDateBefore } from './dateComparison';
+import { msgSortableMs } from './msgSortableMs';
+
+// Robustly resolve a caller-supplied read marker to epoch milliseconds.
+// Callers pass a plain number (the redux read boundary, or a room's
+// lastViewedTimestamp), a Date object (older call sites), or occasionally
+// a numeric string. These are NOT interchangeable through the Date
+// constructor: `new Date(1757000000123)` (a number) reads as epoch-ms,
+// but `new Date("1757000000123")` (a string) is parsed as a date STRING
+// - a bare 13-digit string matches no recognized date format, so the
+// result is silently Invalid Date and every comparison against it is
+// `false`. Try Number() first so a numeric string/number is read as
+// epoch-ms; only fall through to Date parsing for genuine date/ISO
+// strings (e.g. a Date object's own `.toString()`). Never falls back to
+// `Date.now()` - a marker we can't resolve is treated as "no marker",
+// not "now" (bug #38).
+function resolveMarkerMs(
+  marker: number | { toString: () => string } | null | undefined
+): number {
+  if (marker == null) {return 0;}
+  if (typeof marker === 'number') {
+    return Number.isFinite(marker) ? marker : 0;
+  }
+  const raw = marker.toString();
+  if (raw.trim() !== '') {
+    const asNumber = Number(raw);
+    if (Number.isFinite(asNumber)) {return asNumber;}
+  }
+  const parsed = Date.parse(raw);
+  return Number.isFinite(parsed) ? parsed : 0;
+}
 
 function deepMerge(target: any, source: any): any {
   for (const key in source) {
@@ -32,7 +62,7 @@ function deepMerge(target: any, source: any): any {
 export function insertMessageWithDelimiter(
   roomMessages: Partial<IMessage>[],
   message: IMessage,
-  lastViewedTimestamp: { toString: () => string } | null,
+  lastViewedTimestamp: number | { toString: () => string } | null,
 ) {
   const existingIndex = roomMessages.findIndex(
     (msg) =>
@@ -75,33 +105,39 @@ export function insertMessageWithDelimiter(
       roomMessages.push(message);
     }
 
+    const lastViewedMs = resolveMarkerMs(lastViewedTimestamp);
+    const newMessageMs = msgSortableMs(message);
     if (
-      lastViewedTimestamp &&
-      !roomMessages.some((msg) => msg.id === 'delimiter-new') &&
-      isDateAfter(newMessageDate.toString(), lastViewedTimestamp.toString())
+      lastViewedMs > 0 &&
+      newMessageMs > lastViewedMs &&
+      !roomMessages.some((msg) => msg.id === 'delimiter-new')
     ) {
-      const delimiterIndex = roomMessages.findIndex((msg) =>
-        isDateAfter(msg.date?.toString() ?? '', lastViewedTimestamp.toString())
+      // Find the first message STRICTLY newer than the marker, using the
+      // SAME timestamp source (msgSortableMs - the server id-encoded ms)
+      // as the unread middleware and countNewerMessages use to decide
+      // what counts as unread. Comparing against a DIFFERENT source (the
+      // old code compared `msg.date` strings) risks the boundary message
+      // itself landing on the wrong side of the cut: since bug #38 the
+      // marker can equal a real message's own timestamp exactly, and any
+      // drift between `date` and the id-encoded ms - or a raw numeric
+      // marker silently producing an Invalid Date via the Date
+      // constructor's string-parsing path - could count that message as
+      // unread, pushing the divider one message too early (ABOVE the
+      // last read message instead of directly below it). Customer #42.
+      const delimiterIndex = roomMessages.findIndex(
+        (msg) => msg.id !== 'delimiter-new' && msgSortableMs(msg) > lastViewedMs
       );
 
       if (delimiterIndex !== -1) {
         // The divider's date is what ORDERS it: roomsSlice re-sorts every
         // merged page by timestamp (see `byMs`), so a divider stamped with
-        // `new Date()` — i.e. now — sorted past every real message and
+        // `new Date()` (i.e. now) sorted past every real message and
         // rendered at the very bottom, BELOW the new messages it is
         // supposed to introduce. Anchor it a hair before the first unread
         // instead, which is where it belongs and where any later sort keeps
-        // it. Derived from that message rather than from
-        // lastViewedTimestamp so it works whatever format the caller passes.
-        const firstUnreadMs = Date.parse(
-          String(roomMessages[delimiterIndex]?.date ?? '')
-        );
-        const rawLastViewed = lastViewedTimestamp.toString();
-        const lastViewedMs =
-          Date.parse(rawLastViewed) || Number(rawLastViewed) || Date.now();
-        const anchorMs = Number.isFinite(firstUnreadMs)
-          ? firstUnreadMs - 1
-          : lastViewedMs;
+        // it.
+        const firstUnreadMs = msgSortableMs(roomMessages[delimiterIndex]);
+        const anchorMs = firstUnreadMs > 0 ? firstUnreadMs - 1 : lastViewedMs;
 
         roomMessages.splice(delimiterIndex, 0, {
           id: 'delimiter-new',
@@ -116,7 +152,7 @@ export function insertMessageWithDelimiter(
           roomJid: '',
         });
       }
-      }
+    }
   } else if (
     isDateBefore(newMessageDate.toString(), firstMessage?.date?.toString() ?? '')
   ) {

package/src/helpers/isOwnMessage.ts

@@ -0,0 +1,90 @@
+import { IMessage } from '../types/types';
+
+/**
+ * Bug #41: during reconnect catch-up (app was backgrounded/offline, then
+ * comes back online), messages replayed from MAM could transiently render
+ * on the RIGHT (as if sent by the current user) before flipping to the
+ * LEFT a moment later. Root cause: `message.user.id === walletAddress`
+ * treats `undefined === undefined` (or `'' === ''`) as a match, and the
+ * two sides could independently be empty for one frame -- the message's
+ * sender id before the MAM-derived value settled, and/or the current
+ * user's id before it rehydrated. Two blank ids must never compare equal.
+ *
+ * A second, related issue: the same logical sender id can show up in
+ * different shapes depending on which code path produced it -- a bare
+ * id ("wallet123") or a bare JID with an incidental session resource
+ * ("wallet123@host/sessionResource", as `senderJID` attrs carry on the
+ * wire -- see src/assets/test.xml). In every shape used in this
+ * codebase the identifying segment is the part BEFORE the first '@' (or
+ * before '/' when there's no '@'); anything after that -- domain,
+ * resource -- is noise. Comparing raw strings with `===` fails whenever
+ * one side still carries that noise and the other doesn't. Normalizing
+ * both sides (strip resource, strip domain, lowercase) before comparing
+ * makes the check tolerant of that drift.
+ */
+
+export interface OwnMessageUserLike {
+  id?: string | null;
+  xmppUsername?: string | null;
+  walletAddress?: string | null;
+}
+
+export type OwnMessageCurrentUser =
+  | OwnMessageUserLike
+  | string
+  | null
+  | undefined;
+
+/**
+ * Strip a MUC resource (`room@host/resource` -> `room@host`) and then a
+ * JID domain (`local@host` -> `local`), lowercasing the result. Applies
+ * to both plain ids and full/partial JIDs so either shape normalizes to
+ * the same comparable value.
+ */
+const normalizeId = (raw: unknown): string => {
+  const value = String(raw ?? '').trim();
+  if (!value) {
+    return '';
+  }
+  const withoutResource = value.split('/')[0];
+  const withoutDomain = withoutResource.includes('@')
+    ? withoutResource.split('@')[0]
+    : withoutResource;
+  return withoutDomain.toLowerCase();
+};
+
+// Same precedence the rest of the app uses when it needs "who am I" as a
+// single id: xmppUsername first, walletAddress as the fallback.
+const resolveCurrentUserId = (currentUser: OwnMessageCurrentUser): string => {
+  if (typeof currentUser === 'string') {
+    return currentUser;
+  }
+  if (!currentUser) {
+    return '';
+  }
+  return (
+    currentUser.xmppUsername || currentUser.walletAddress || currentUser.id || ''
+  );
+};
+
+/**
+ * Robustly determine whether `message` was sent by `currentUser`. Never
+ * returns true from two blank/undefined ids, and tolerates bare-id vs.
+ * full-JID mismatches between the sender id and the current user id.
+ */
+export const isOwnMessage = (
+  message: Pick<IMessage, 'user'> | null | undefined,
+  currentUser: OwnMessageCurrentUser
+): boolean => {
+  const messageUserId = normalizeId(message?.user?.id);
+  if (!messageUserId) {
+    return false;
+  }
+
+  const currentUserId = normalizeId(resolveCurrentUserId(currentUser));
+  if (!currentUserId) {
+    return false;
+  }
+
+  return messageUserId === currentUserId;
+};

package/src/helpers/keyboardLayout.ts

@@ -14,9 +14,30 @@ export const getKeyboardVerticalOffset = ({
 }: KeyboardLayoutArgs): number =>
   configuredOffset + (platform === 'ios' ? bottomInset : 0);
 
+type InputDockPaddingArgs = Omit<KeyboardLayoutArgs, 'configuredOffset'> & {
+  // Explicit `inputDockPaddingBottom` config value, verbatim on both
+  // platforms when provided (0 allowed). Takes priority over every other
+  // rule below, including `hostOwnsLayout`.
+  configuredPadding?: number;
+  // True when the host app owns keyboard layout entirely (i.e.
+  // `disableKeyboardAvoidingView` is set) and `configuredPadding` was not
+  // given. The dock then gets no built-in bottom padding of its own,
+  // since it already sits above the host's own chrome (e.g. its tab bar).
+  hostOwnsLayout?: boolean;
+};
+
 export const getInputDockPaddingBottom = ({
   platform,
   bottomInset = 0,
   keyboardVisible = false,
-}: Omit<KeyboardLayoutArgs, 'configuredOffset'>): number =>
-  platform === 'ios' ? bottomInset : ANDROID_INPUT_DOCK_GAP;
+  configuredPadding,
+  hostOwnsLayout = false,
+}: InputDockPaddingArgs): number => {
+  if (typeof configuredPadding === 'number') {
+    return configuredPadding;
+  }
+  if (hostOwnsLayout) {
+    return 0;
+  }
+  return platform === 'ios' ? bottomInset : ANDROID_INPUT_DOCK_GAP;
+};

package/src/helpers/mediaLibraryRuntime.ts

@@ -0,0 +1,25 @@
+let cached: any | undefined;
+
+export const getMediaLibrary = (): any | null => {
+  if (cached !== undefined) {return cached;}
+  try {
+    const legacy = require('expo-media-library/legacy');
+
+    if (legacy?.getAssetsAsync) {
+      cached = legacy;
+      return cached;
+    }
+  } catch {
+  }
+
+  try {
+    cached = require('expo-media-library') ?? null;
+  } catch {
+    cached = null;
+  }
+  return cached;
+};
+
+export const __resetMediaLibraryCache = () => {
+  cached = undefined;
+};

package/src/helpers/mimeToExtension.ts

@@ -289,25 +289,9 @@ export function ensureFilenameHasExtension(
   return `${base}${getExtensionForMime(mime)}`;
 }
 
-/**
- * Best-effort filename derivation for a message bubble:
- *   - server-provided `fileName`
- *   - server-provided `originalName`
- *   - URL pathname
- *   - generic `media_<timestamp>` so we never render an empty label
- *
- * Always returns a string with a valid extension.
- */
-export function deriveDisplayFilename(opts: {
-  fileName?: string | null;
-  originalName?: string | null;
-  url?: string | null;
-  mime?: string | null;
-}): string {
-  const candidate =
-    (opts.fileName && opts.fileName.trim()) ||
-    (opts.originalName && opts.originalName.trim()) ||
-    filenameFromUrl(opts.url) ||
-    '';
-  return ensureFilenameHasExtension(candidate, opts.mime);
-}
+// NOTE: the "which name wins" decision (originalName vs the stored
+// fileName vs the URL) lives in helpers/getDisplayFileName.ts - that is
+// the single source of truth used across display, save, share and
+// download call sites (bug #40: this used to be duplicated here with
+// the priority backwards, so attachments showed/saved under the
+// server's hash name instead of the sender's original one).

package/src/helpers/msgSortableMs.ts

@@ -0,0 +1,25 @@
+// Count messages strictly newer than a given millisecond timestamp using
+// `msg.id` (the server-authoritative microsecond timestamp prefixed by a
+// 13-digit millis, see `helpers/dateComparison`'s
+// `getHighResolutionTimestamp`) rather than `msg.date`, which can be
+// derived client-side (`createMessageFromXml` falls back to `Date.now()`
+// for realtime stanzas without a `date` attr) and drift from what the
+// server actually assigned.
+//
+// Extracted to its own module (rather than living in roomsSlice.ts, its
+// original home) so helpers that need the SAME ordering source - notably
+// `insertMessageWithDelimiter.ts`, which decides where the "New messages"
+// divider sits - can import it without creating a roomStore <-> helpers
+// import cycle (roomsSlice.ts already imports insertMessageWithDelimiter).
+// roomsSlice.ts re-exports this for backward compatibility with existing
+// call sites.
+export const msgSortableMs = (msg: any): number => {
+  const id = String(msg?.id || '');
+  const m = /^(\d{13})/.exec(id);
+  if (m) {return Number(m[1]);}
+  if (msg?.date) {
+    const t = new Date(msg.date as any).getTime();
+    if (Number.isFinite(t)) {return t;}
+  }
+  return 0;
+};