@ethora/chat-component-rn 26.7.7 → 26.7.9

package/src/components/RoomComponents/styled/LastMessageVideo.tsx

@@ -10,6 +10,7 @@ import {
   ShadeWrapper,
 } from './StyledRoomComponents';
 import { Text, View } from 'react-native';
+import { getDisplayFileName } from '../../../helpers/getDisplayFileName';
 
 const VideoContainer = styled.View`
   position: relative;
@@ -40,14 +41,25 @@ const PlayButton = styled.View`
 `;
 
 interface LastMessageVideoProps
-  extends Pick<LastMessage, 'user' | 'location' | 'originalName'> {}
+  extends Pick<
+    LastMessage,
+    'user' | 'location' | 'originalName' | 'fileName' | 'mimetype'
+  > {}
 
 const LastMessageVideo: FC<LastMessageVideoProps> = ({
   user,
   location,
   originalName,
+  fileName,
+  mimetype,
 }) => {
   const fileToken = useFileToken();
+  // Bug #40: prefer the sender's original name over the stored hash
+  // name; only fall back to the generic "file" label when neither is
+  // present at all (avoids a synthetic "media_<timestamp>.bin" here).
+  const displayName = originalName || fileName
+    ? getDisplayFileName({ originalName, fileName, mimetype })
+    : 'file';
   return (
     <LastRoomMessageContainer>
       <LastRoomMessageName>{user?.name || ''}:</LastRoomMessageName>
@@ -64,7 +76,7 @@ const LastMessageVideo: FC<LastMessageVideoProps> = ({
           </ShadeWrapper>
           <PlayButton><Text>▶</Text></PlayButton>
         </VideoContainer>
-        <LastRoomMessageText>{originalName || 'file'}</LastRoomMessageText>
+        <LastRoomMessageText>{displayName}</LastRoomMessageText>
       </View>
     </LastRoomMessageContainer>
   );

package/src/components/styled/MessageImage.tsx

@@ -22,6 +22,12 @@ interface CustomMessageImageProps {
   /** Full-size file. Opened in the preview modal, NOT rendered inline. */
   fileURL: string;
   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;
   mimetype: string;
   /**
    * Server-generated thumbnail — what the bubble actually renders, same
@@ -42,6 +48,7 @@ const FALLBACK_IMAGE =
 const CustomMessageImage: React.FC<CustomMessageImageProps> = ({
   fileURL,
   fileName,
+  originalName,
   mimetype,
   locationPreview,
 }) => {
@@ -84,7 +91,7 @@ const CustomMessageImage: React.FC<CustomMessageImageProps> = ({
   }, [displayURL]);
 
   const handleOpen = () => {
-    dispatch(setActiveFile({ fileName, fileURL, mimetype }));
+    dispatch(setActiveFile({ fileName, fileURL, mimetype, originalName }));
     dispatch(setActiveModal(MODAL_TYPES.FILE_PREVIEW));
   };
 

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,9 @@ import {
   clearVisibleRoom,
   setLastViewedTimestamp,
   deleteRoomMessage,
-  msgSortableMs,
   setUnreadSyncing,
 } from '../roomStore/roomsSlice';
+import { getServerReadTimestamp } from '../helpers/getServerReadTimestamp';
 import { runHistoryPreloadScheduler } from '../helpers/historyPreloadScheduler';
 import { updateMessagesTillLast } from '../helpers/updateMessagesTillLast';
 import { secureUserStorage } from '../helpers/secureUserStorage';
@@ -638,16 +638,30 @@ 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=<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.
       visibleBeforeBackground = visibleRoomJID;
       if (visibleRoomJID) {
-        store.dispatch(
-          setLastViewedTimestamp({ chatJID: visibleRoomJID, timestamp: Date.now() })
+        const readTs = getServerReadTimestamp(
+          rooms?.[visibleRoomJID],
+          state.roomHeapSlice
         );
+        // 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).
@@ -672,11 +686,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(() => {
@@ -692,9 +706,18 @@ export const XmppProvider: React.FC<XmppProviderProps> = ({ children, config, is
       }
     } else {
       if (wasVisible && activeRoomJID) {
-        store.dispatch(
-          setLastViewedTimestamp({ chatJID: activeRoomJID, timestamp: Date.now() })
+        // 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).
+        const readTs = getServerReadTimestamp(
+          rooms?.[activeRoomJID],
+          state.roomHeapSlice
         );
+        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(
@@ -726,18 +749,18 @@ 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;}
+      // getServerReadTimestamp (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).
+      const newest = getServerReadTimestamp(room, s.roomHeapSlice);
+      if (!newest || newest <= lastStampedMs) {return;}
       lastStampedMs = newest;
 
       store.dispatch(
-        setLastViewedTimestamp({ chatJID: jid, timestamp: Date.now() })
+        setLastViewedTimestamp({ chatJID: jid, timestamp: newest })
       );
 
       if (flushTimer) {clearTimeout(flushTimer);}

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,120 @@
+import type { IMessage, IRoom } from '../types/types';
+import { msgSortableMs } from '../roomStore/roomsSlice';
+
+// 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` (roomsSlice.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;
+}

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) {

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/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).