@antzsoft/chat-core 1.3.6 → 1.3.8

package/README.md

@@ -2656,6 +2656,7 @@ Returned by `messagesApi.getReceipts()`. Use as the initial load for a "Read by
 ```typescript
 interface MessageReceiptEntry {
   userId: string;
+  externalId?: string;    // external system user ID (non-builtin modes)
   displayName: string;
   avatarUrl?: string;
 }
@@ -2685,6 +2686,7 @@ Returned by `messagesApi.getReactions()`. Use as the data source for a reactions
 ```typescript
 interface ReactionUser {
   userId: string;
+  externalId?: string;    // external system user ID (non-builtin modes)
   displayName: string;
   avatarUrl?: string;
 }
@@ -2801,6 +2803,7 @@ interface MessageConfig {
 ```typescript
 interface Participant {
   userId: string;
+  externalId?: string;    // external system user ID (non-builtin modes); mirrored on user.externalId
   role: 'admin' | 'member';
   joinedAt: string;
   isActive?: boolean;
@@ -2893,6 +2896,7 @@ interface ReactionUpdatedEvent {
 interface TypingIndicatorEvent {
   conversationId: string;
   userId: string;
+  externalId?: string;    // external system user ID (non-builtin modes); absent in builtin mode
   username: string;
   displayName: string;
   avatarUrl?: string;
@@ -3056,6 +3060,34 @@ document.querySelectorAll('[data-conv-id]').forEach((el) => {
 
 ## Changelog
 
+### v1.3.8
+
+- **`externalId` now surfaced on every embedded user shape, not just the standalone user profile.** Previously `externalId` (the user's ID in your external system, non-builtin modes) was only present on `User` returned from `usersApi.list/getById/updateProfile`. Every *denormalized* place a user appeared — conversation participants, message sender, reaction users, and read/delivery receipts — dropped it, forcing a separate `usersApi.getById()` call to map a chat user back to your own system. Those shapes now carry `externalId`:
+
+  - **`Participant`** — new top-level `externalId?` field, also mirrored onto `Participant.user.externalId`. (`conversationsApi` + conversation socket events.)
+  - **`Message.sender`** — now includes `externalId` (it is a `User`, so the field was always in the type; the server now populates it on the embed).
+  - **`ReactionUser`** (`messagesApi.getReactions`) — new `externalId?`.
+  - **`MessageReceiptEntry`** (`messagesApi.getReceipts`) — new `externalId?`.
+  - **`TypingIndicatorEvent`** (socket) — new `externalId?`. Present in non-builtin modes; **absent in builtin mode**, where no external identity exists.
+
+  **Backward compatible, additive-only.** Every field is optional (`externalId?`). An older SDK against this server simply ignores the extra field; this SDK against an older server sees `externalId` as `undefined`. Note `externalId` (a string, the chat user's external identity) is distinct from the pre-existing `Participant`-level `externalUserId` (a number) — both are sent; do not confuse them. Requires server v-with-this-change or newer to be populated; safe to upgrade regardless. **No integration changes required** — read `externalId` where you previously had to look it up separately.
+
+### v1.3.7
+
+- **Docs only — no code changes.** Brought the docs fully up to date: added the missing
+  release notes to `docs/integration-guide.html` (its "What's New" section had stopped at
+  v1.3.4) so both the README changelog and the HTML integration guide now cover v1.3.5,
+  v1.3.6, and this v1.3.7 entry. No SDK behaviour changed in this version; upgrading from
+  1.3.6 is a no-op at runtime.
+
+### v1.3.6
+
+- **Fix: `reconnectSocket` now PRESERVES the transit session instead of recreating it** — follow-up to the 1.3.5 reconnect fix. 1.3.5 fixed `"Transit encryption required"` by disconnecting and re-running the full `connectSocket()` handshake, but that also cleared the cached transit session (the `'disconnect'` handler calls `clearTransitSession()`) and established a brand-new one with a new session key. Server-broadcast events (e.g. `user_online`) are encrypted with the session the server still holds, so a fresh client key could not decrypt them → continuous `"Transit decryption failed for event: user_online"`.
+
+  `reconnectSocket` is a token-only refresh — the transit session is still valid on the server (stored in Redis by `sessionId`, re-linked to the new socket on reconnect). So it now carries the existing `transitSessionId` forward in the handshake auth and reconnects the **same** socket **without** disconnecting, keeping the client's session key intact. The server re-links the same session (`getBySessionId` + `linkSocket`), so both sides keep the same key and decryption continues to work. Falls back to the full `connectSocket()` flow only when there is no valid cached session to preserve.
+
+  Net: keeps 1.3.5's "no more `Transit encryption required` on reconnect" while removing the `user_online` decryption-failure regression. **No integration changes required.**
+
 ### v1.3.5
 
 - **Fix: `reconnectSocket()` no longer drops the transit-encryption handshake** — when transit encryption is enabled, `reconnectSocket()` now delegates to the full `connectSocket()` flow instead of doing a bare `_socket.auth` swap. `reconnectSocket()` predates transit encryption and was never migrated: it overwrote `_socket.auth` with only `{ token, userId, tenantId }`, dropping the `transitSessionId` / `transitEphemeralPub` fields that `connectSocket()` sets during the handshake. Combined with the `'disconnect'` handler clearing the cached transit session, a reconnect after the socket had disconnected (e.g. app returning to foreground on iOS/Android, where backgrounding fully disconnects) went out with no transit auth and no cached session → the server rejected the handshake with **"Transit encryption required: missing transitEphemeralPub/transitAlgo in handshake auth"**. It was intermittent — fast devices whose cached transit session survived the reconnect were unaffected.

package/dist/index.cjs

@@ -1105,11 +1105,13 @@ function normalizeParticipant(p) {
   const hasUserDetails = p.displayName || p.username || p.avatarUrl;
   return {
     userId: p.userId,
+    externalId: p.externalId ?? p.user?.externalId,
     role: p.role,
     joinedAt: p.joinedAt,
     isActive: p.isActive,
     user: hasUserDetails ? {
       id: p.userId,
+      externalId: p.externalId,
       tenantId: "",
       email: "",
       username: p.username ?? "",