@antzsoft/chat-core 1.0.9 → 1.1.1

package/docs/integration-guide.html

@@ -155,7 +155,7 @@ section.sec>h2:hover{color:#fff}
 
   <div class="section-label">What's New</div>
   <ul>
-    <li><a href="#whats-new">v1.0.9 Release Notes</a></li>
+    <li><a href="#whats-new">v1.1.0 Release Notes</a></li>
   </ul>
 
   <div class="section-label">Getting Started</div>
@@ -242,12 +242,125 @@ section.sec>h2:hover{color:#fff}
   <h2>What's New</h2>
   <p style="color:var(--muted);font-size:13px;margin-bottom:20px">Version history and release notes. Click a version to expand.</p>
 
-  <!-- ── v1.0.9 (current) ── -->
-  <div class="wn-version open" id="wn-109">
+  <!-- ── v1.1.0 (current) ── -->
+  <div class="wn-version open" id="wn-110">
+    <div class="wn-header" onclick="toggleVersion('wn-110')">
+      <div class="wn-title">
+        <span class="wn-ver">v1.1.0</span>
+        <span class="wn-badge current">Current</span>
+        <span class="wn-date">May 2026</span>
+      </div>
+      <span class="wn-chevron">▲</span>
+    </div>
+    <div class="wn-body">
+
+      <div class="wn-item" id="wn-110-1">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-1')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">500 error on device token registration after reinstall or account switch</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>Registering a push token (Expo, FCM, APNs) that was previously registered under a different user or device ID returned a 500. This happened because the global <code>token_unique</code> sparse index rejected the duplicate before the upsert could complete.</p>
+          <p>Common triggers: app reinstall (new <code>deviceId</code> UUID generated), user switches account on same device, or token reuse after logout/login.</p>
+          <p>The server now removes any stale record holding the same token under a different owner before performing the upsert. Registration always succeeds for the new owner.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-2">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-2')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">500 error when removing a participant from a conversation</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>Removing a participant caused a server error in certain cases. Message delivery stops and socket room eviction now correctly target only the remaining active members.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-3">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-3')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Leave group now works for removed members</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>After an admin removed a user from a group, that user still saw the conversation in their list (read-only, by design since v1.0.8). However, calling <code>leave()</code> to dismiss it returned a <strong>403 Forbidden</strong> because the active-participant guard rejected inactive users.</p>
+          <p><code>leave()</code> now uses read-access validation instead. If the caller is already inactive (removed), the conversation is hidden from their list immediately — no removal step is re-executed. If the caller is still active, the existing leave flow runs unchanged.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-4">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-4')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Group auto-disbands when last active member leaves or is removed</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>When the last active participant left or was removed, the group conversation persisted in the database as an orphan with zero active members. It could never be accessed or cleaned up.</p>
+          <p>The server now marks the conversation <code>isActive: false</code> automatically when <code>remainingParticipantIds</code> drops to zero after a leave or remove operation.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-5">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-5')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title"><code>lastMessage</code> content not updating after message edit</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>Editing a message that was also the conversation's last message did not update <code>conversation.lastMessage.contentPreview</code>. The conversation list kept showing the original text until a new message was sent.</p>
+          <p>The server now refreshes <code>lastMessage.contentPreview</code> on edit when the edited message ID matches <code>conversation.lastMessage.messageId</code>.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-6">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-6')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Reply-to attachment preview shows filename or file type instead of <code>[Attachment]</code></span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>When replying to a message that contained an attachment, the quoted preview always showed the generic string <code>[Attachment]</code>. The server now returns the filename if available, otherwise the file type (e.g. <code>image</code>, <code>video</code>, <code>document</code>).</p>
+          <p>For previewable types (images, video), clients should use the parent message's attachment data (already included in the reply payload) to render a thumbnail or inline preview.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-7">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-7')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Remove reaction no longer errors when reaction does not exist</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>Removing a reaction that had already been removed (or never existed) returned a 500. The operation is now idempotent — removing a non-existent reaction returns success.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-110-8">
+        <div class="wn-item-header" onclick="toggleItem('wn-110-8')">
+          <span class="wn-tag new">New</span>
+          <span class="wn-item-title">Pin limit — max 5 pinned conversations</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>The server now enforces a maximum of <strong>5 pinned conversations</strong> per user. Attempting to pin a sixth returns a <code>400</code> error.</p>
+          <p>A new <code>GET /app/config</code> endpoint exposes server-side limits to clients. Use <code>appConfigApi.get()</code> to fetch them:</p>
+          <pre><code><span class="kw">const</span> config = <span class="kw">await</span> appConfigApi.<span class="fn">get</span>();
+<span class="cm">// { maxPinnedConversations: 5 }</span></code></pre>
+          <p><code>useConversations()</code> (Web + RN) now fetches config automatically on mount, blocks the <code>pin</code> mutation client-side before it hits the API when the limit is reached, and exposes <code>maxPinnedConversations</code> for UI gating (e.g. hiding the pin option).</p>
+          <p>The RN <code>ConversationList</code> component now supports long-press to pin/unpin — this action was previously missing on React Native.</p>
+        </div>
+      </div>
+
+    </div>
+  </div><!-- /.wn-version -->
+
+  <!-- ── v1.0.9 ── -->
+  <div class="wn-version" id="wn-109">
     <div class="wn-header" onclick="toggleVersion('wn-109')">
       <div class="wn-title">
         <span class="wn-ver">v1.0.9</span>
-        <span class="wn-badge current">Current</span>
         <span class="wn-date">May 2026</span>
       </div>
       <span class="wn-chevron">▲</span>
@@ -263,7 +376,6 @@ section.sec>h2:hover{color:#fff}
         <div class="wn-item-body">
           <p>On Android, the OS suspends idle WebSocket connections during long operations such as audio recording. When <code>sendMessage</code> was called immediately after a file upload completed, the socket was still reconnecting and the call failed immediately with "Socket not connected".</p>
           <p><code>sendMessage</code> now waits up to <strong>15 seconds</strong> for Socket.IO to auto-reconnect before attempting to send. Once the connection is restored the message goes through normally — no error, no retry logic needed in the app.</p>
-          <p><strong>Action required:</strong> None. Behavior change is inside the SDK. No API or type changes.</p>
         </div>
       </div>
 
@@ -306,9 +418,8 @@ section.sec>h2:hover{color:#fff}
           <span class="wn-chevron-sm">▾</span>
         </div>
         <div class="wn-item-body">
-          <p>When sending a message with an attachment and <code>text: ""</code>, the empty string was being stored in the database and returned as-is instead of being treated as absent. This caused the conversation-list preview for attachment-only messages to show blank instead of falling back to the filename or "Attachment".</p>
-          <p>Both the HTTP API and socket paths now trim the text input and treat empty strings as absent before saving to the database. The preview now correctly shows the filename or "Attachment" for attachment-only messages.</p>
-          <p><strong>Action required:</strong> None. Server-side fix only. No SDK or type changes.</p>
+          <p>When sending a message with an attachment and <code>text: ""</code>, the empty string was stored and returned instead of being treated as absent. The conversation-list preview for attachment-only messages showed blank instead of the filename or "Attachment". Both the HTTP and socket paths now trim and treat empty strings as absent before saving.</p>
+          <p><strong>Action required:</strong> None. Server-side fix only.</p>
         </div>
       </div>
 
@@ -319,9 +430,72 @@ section.sec>h2:hover{color:#fff}
           <span class="wn-chevron-sm">▾</span>
         </div>
         <div class="wn-item-body">
-          <p>The <code>participant_left</code> socket event was only broadcast to the <code>conversation:&lt;id&gt;</code> room. Users only join that room when they actively open that specific conversation — so anyone on the conversation-list screen (or any other screen) never received the event and saw a stale participant count.</p>
-          <p>The server now also emits directly to each remaining participant's personal <code>user:&lt;tenantId&gt;:&lt;userId&gt;</code> room, which every connected user joins on connect. To prevent users who have the conversation open from receiving the event twice (and double-decrementing the count), the server checks whether any of the user's sockets are already in the conversation room before sending the personal-room emit.</p>
-          <p><strong>Action required:</strong> None. Server-side fix only. No SDK or type changes.</p>
+          <p>The <code>participant_left</code> socket event was only broadcast to the <code>conversation:&lt;id&gt;</code> room. Users only join that room when they actively open that specific conversation — so users on the conversation-list screen never received the event and saw a stale participant count. The server now also emits directly to each remaining participant's personal <code>user:&lt;tenantId&gt;:&lt;userId&gt;</code> room, skipping users already in the conversation room to avoid double-delivery.</p>
+          <p><strong>Action required:</strong> None. Server-side fix only.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-109-6">
+        <div class="wn-item-header" onclick="toggleItem('wn-109-6')">
+          <span class="wn-tag new">New</span>
+          <span class="wn-item-title">Pin limit — max 5 pinned conversations + <code>appConfigApi</code></span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>The server now enforces a maximum of <strong>5 pinned conversations</strong> per user. Attempting to pin a 6th returns <code>400 Bad Request: "You can only pin up to 5 conversations"</code>.</p>
+          <p>A new <code>GET /app/config</code> endpoint returns server-side limits so clients can gate the UI without hardcoding values:</p>
+          <pre><code><span class="kw">import</span> { appConfigApi } <span class="kw">from</span> <span class="str">'@antzsoft/chat-core'</span>;
+<span class="kw">const</span> config = <span class="kw">await</span> appConfigApi.<span class="fn">get</span>();
+<span class="cm">// { maxPinnedConversations: 5 }</span></code></pre>
+          <ul>
+            <li><code>useConversations()</code> (Web + RN) now fetches this automatically and exposes <code>maxPinnedConversations</code></li>
+            <li>The <code>pin</code> mutation in <code>useConversations()</code> throws before hitting the network if the limit is already reached</li>
+            <li>RN SDK <code>ConversationList</code> now shows pin/unpin on long-press (was missing previously)</li>
+          </ul>
+          <p><strong>Action required:</strong> None for SDK users — built-in check handles it. Raw API users should call <code>appConfigApi.get()</code> on init and gate the pin button using <code>config.maxPinnedConversations</code>.</p>
+          <p class="wn-ref">→ <a href="#step-conversations">Step 6 — Conversations</a></p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-109-7">
+        <div class="wn-item-header" onclick="toggleItem('wn-109-7')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Removed user could re-enter conversation room via <code>join_room</code></span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>The socket access check for <code>join_room</code> was missing the <code>isActive</code> participant check. A removed user whose client re-emitted <code>joinRoom</code> (e.g. on reconnect or by navigating back to the chat screen) would be silently re-admitted to the conversation room and continue receiving <code>new_message</code> events. The check now requires <code>isActive: true</code>, consistent with the write-access check.</p>
+          <p><strong>Action required:</strong> None. Server-side fix only.</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-109-8">
+        <div class="wn-item-header" onclick="toggleItem('wn-109-8')">
+          <span class="wn-tag fix">Fix</span>
+          <span class="wn-item-title">Re-added user's conversation missing from list when they had previously deleted it</span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p>When a user deleted a conversation (<code>isHidden: true</code>), was then removed from the group, and later re-added by an admin, the conversation never reappeared in their list. The reactivation path now resets <code>isHidden</code> to <code>false</code> alongside <code>isActive</code>.</p>
+          <p>Additionally, the server now server-side joins the re-added user's active sockets into the conversation room and emits <code>conversation_created</code> to their personal room so the conversation appears immediately — no reconnect or <code>joinRoom</code> call needed.</p>
+          <p><strong>Action required:</strong> None. Server-side fix only. Existing <code>conversation_created → joinRoom</code> listeners remain safe (idempotent).</p>
+        </div>
+      </div>
+
+      <div class="wn-item" id="wn-109-9">
+        <div class="wn-item-header" onclick="toggleItem('wn-109-9')">
+          <span class="wn-tag new">New</span>
+          <span class="wn-item-title">Optional <code>role</code> parameter on <code>addParticipants</code></span>
+          <span class="wn-chevron-sm">▾</span>
+        </div>
+        <div class="wn-item-body">
+          <p><code>addParticipants</code> now accepts an optional <code>role</code> parameter (<code>'admin' | 'member'</code>, default <code>'member'</code>). This applies to both newly added users and previously removed users being re-added. A former admin who is re-added without specifying <code>role: 'admin'</code> will come back as a member — their previous role is never silently restored.</p>
+          <pre><code><span class="cm">// Default — added as member (backward compatible)</span>
+<span class="kw">await</span> conversationsApi.<span class="fn">addParticipants</span>(conversationId, [<span class="str">'user-3'</span>]);
+
+<span class="cm">// Explicitly add as admin</span>
+<span class="kw">await</span> conversationsApi.<span class="fn">addParticipants</span>(conversationId, [<span class="str">'user-3'</span>], <span class="str">'admin'</span>);</code></pre>
+          <p><strong>Action required:</strong> None for existing code — the parameter is optional and defaults to <code>'member'</code>. No call sites need updating unless you want to add members as admins directly.</p>
         </div>
       </div>
 
@@ -329,7 +503,7 @@ section.sec>h2:hover{color:#fff}
   </div>
 
   <!-- ── v1.0.8 ── -->
-  <div class="wn-version open" id="wn-108">
+  <div class="wn-version" id="wn-108">
     <div class="wn-header" onclick="toggleVersion('wn-108')">
       <div class="wn-title">
         <span class="wn-ver">v1.0.8</span>
@@ -375,7 +549,6 @@ section.sec>h2:hover{color:#fff}
             <li>Cannot send, react, type, edit, or delete — <code>validateWriteAccess</code> blocks all write operations</li>
           </ul>
           <p>This is implemented via a new <code>isHidden</code> field on the <code>Participant</code> subdocument (schema change, server only). The conversation list filter now shows conversations where the user is not hidden, regardless of <code>isActive</code>.</p>
-          <p><strong>Action required:</strong> None. Behavior change is entirely server-side. SDK types and API calls are unchanged.</p>
         </div>
       </div>
 
@@ -388,7 +561,6 @@ section.sec>h2:hover{color:#fff}
         <div class="wn-item-body">
           <p>Previously, when an admin called <code>deleteConversation</code> it set <code>conversation.isActive = false</code>, making it disappear for <em>all</em> participants. This was wrong — only the admin who deleted it should lose access.</p>
           <p>Now, <code>deleteConversation</code> sets <code>participant.isHidden = true</code> for the requesting user only. All other participants continue to see the conversation normally.</p>
-          <p><strong>Action required:</strong> None. Server-side change only.</p>
         </div>
       </div>
 
@@ -401,7 +573,6 @@ section.sec>h2:hover{color:#fff}
         <div class="wn-item-body">
           <p>When a message was deleted, <code>lastMessage.status</code> on the conversation was set to <code>'deleted'</code>. Sending a new message afterwards never reset it — so the conversation list kept showing <code>deleted</code> as the last message state indefinitely.</p>
           <p>Root cause: two separate code paths update <code>lastMessage</code> (REST and WebSocket) and neither was explicitly setting <code>status: 'active'</code> when writing a new message. Fixed in both paths.</p>
-          <p><strong>Action required:</strong> None. Server-side fix only.</p>
         </div>
       </div>
 
@@ -431,7 +602,7 @@ section.sec>h2:hover{color:#fff}
   </div>
 
   <!-- ── v1.0.7 ── -->
-  <div class="wn-version open" id="wn-107">
+  <div class="wn-version" id="wn-107">
     <div class="wn-header" onclick="toggleVersion('wn-107')">
       <div class="wn-title">
         <span class="wn-ver">v1.0.7</span>
@@ -468,7 +639,7 @@ section.sec>h2:hover{color:#fff}
         </div>
         <div class="wn-item-body">
           <p>The server now accepts <code>audio/m4a</code> and <code>audio/x-m4a</code> MIME types for audio attachments. Previously only <code>audio/mpeg</code>, <code>audio/ogg</code>, and <code>audio/wav</code> were accepted — uploads of <code>.m4a</code> files returned a <code>400</code> unsupported type error.</p>
-          <p><strong>Action required:</strong> No SDK change needed. If you were filtering <code>.m4a</code> files out in the client before upload, remove that restriction.</p>
+          <p>If you were filtering <code>.m4a</code> files out in the client before upload, remove that restriction.</p>
         </div>
       </div>
 
@@ -1407,15 +1578,33 @@ chatClient.<span class="fn">disconnect</span>();
 
 <span class="cm">// Participants</span>
 <span class="kw">const</span> members = <span class="kw">await</span> conversationsApi.<span class="fn">getMembers</span>(conversationId);
-<span class="kw">await</span> conversationsApi.<span class="fn">addParticipants</span>(conversationId, [<span class="str">'user-3'</span>]);
+<span class="kw">await</span> conversationsApi.<span class="fn">addParticipants</span>(conversationId, [<span class="str">'user-3'</span>]);               <span class="cm">// added as member (default)</span>
+<span class="kw">await</span> conversationsApi.<span class="fn">addParticipants</span>(conversationId, [<span class="str">'user-3'</span>], <span class="str">'admin'</span>);  <span class="cm">// added as admin</span>
 <span class="kw">await</span> conversationsApi.<span class="fn">removeParticipant</span>(conversationId, <span class="str">'user-2'</span>);
 <span class="kw">await</span> conversationsApi.<span class="fn">updateParticipantRole</span>(conversationId, <span class="str">'user-1'</span>, <span class="str">'admin'</span>);
 
 <span class="cm">// Pin · Mute · Leave · Delete</span>
-<span class="kw">await</span> conversationsApi.<span class="fn">pin</span>(conversationId);
+<span class="kw">await</span> conversationsApi.<span class="fn">pin</span>(conversationId);   <span class="cm">// 400 if already at 5 pinned</span>
 <span class="kw">await</span> conversationsApi.<span class="fn">mute</span>(conversationId, <span class="str">'2025-12-31T23:59:59Z'</span>); <span class="cm">// omit date = indefinite</span>
 <span class="kw">await</span> conversationsApi.<span class="fn">leave</span>(conversationId);
 <span class="kw">await</span> conversationsApi.<span class="fn">delete</span>(conversationId); <span class="cm">// admin only</span></code></pre>
+
+  <div class="callout info">
+    <strong>Pin limit — max 5</strong> — The server enforces a maximum of 5 pinned conversations per user. Attempting to pin a 6th returns <code>400 Bad Request</code>. Gate your UI before calling the API:
+    <pre style="margin-top:8px"><code><span class="kw">import</span> { appConfigApi } <span class="kw">from</span> <span class="str">'@antzsoft/chat-core'</span>;
+
+<span class="cm">// Fetch once on init — SDK caches under ['app-config'] with staleTime: Infinity</span>
+<span class="kw">const</span> config = <span class="kw">await</span> appConfigApi.<span class="fn">get</span>();  <span class="cm">// { maxPinnedConversations: 5 }</span>
+
+<span class="cm">// Before calling pin:</span>
+<span class="kw">const</span> pinnedCount = conversations.<span class="fn">filter</span>(c => c.isPinned).length;
+<span class="kw">if</span> (pinnedCount >= config.maxPinnedConversations) {
+  <span class="cm">// show error toast — do NOT call the API</span>
+  <span class="kw">return</span>;
+}
+<span class="kw">await</span> conversationsApi.<span class="fn">pin</span>(conversationId);</code></pre>
+    <p>If you use <code>useConversations()</code> (Web/RN SDK), this check is built in — the <code>pin</code> mutation throws before hitting the network if the limit is reached. The hook also exposes <code>maxPinnedConversations</code> to disable the pin button in your UI.</p>
+  </div>
 </section>
 
 <!-- ─── STEP 7: ROOMS ──────────────────────────────────────────────────── -->
@@ -1436,16 +1625,15 @@ chatClient.<span class="fn">disconnect</span>();
 
   <h4>When to call <code>joinRoom</code></h4>
   <p>
-    There is only one real use case — when the <strong>user is added to a conversation while their socket is already connected</strong>
-    (either someone created a new group and added them, or they were added to an existing group at runtime).
-    The server does <strong>not</strong> auto-join the user's socket to the new room — it only emits <code>conversation_created</code>
-    to the user's personal room. Without calling <code>joinRoom</code>, the socket will not receive any
-    <code>new_message</code>, <code>typing_indicator</code>, or other room events for that conversation.
+    When the <strong>user is added to a conversation while their socket is already connected</strong>, the server now automatically joins their active sockets into the new room and emits <code>conversation_created</code> to their personal room. No <code>joinRoom</code> call is required — <code>new_message</code>, <code>typing_indicator</code>, and all other room events will arrive immediately.
+  </p>
+  <p>
+    Calling <code>joinRoom</code> on <code>conversation_created</code> is still safe (idempotent) and can be kept for defensive compatibility, but is no longer necessary:
   </p>
 
-  <pre><code><span class="cm">// Fires when you're added to a new or existing conversation at runtime</span>
+  <pre><code><span class="cm">// Optional — server already handles this automatically</span>
 client.socket.<span class="fn">on</span>(<span class="str">'conversation_created'</span>, (conv) => {
-  client.socket.emit.<span class="fn">joinRoom</span>(conv.id);
+  client.socket.emit.<span class="fn">joinRoom</span>(conv.id); <span class="cm">// safe no-op if already in room</span>
 });</code></pre>
 
   <p><code>leaveRoom</code> is only needed if you want to intentionally stop receiving events for a room the user is still a member of (e.g. archiving client-side). It is not needed when navigating away from a screen.</p>
@@ -1476,9 +1664,9 @@ client.socket.<span class="fn">on</span>(<span class="str">'new_message'</span>,
   });
 });
 
-<span class="cm">// Only case where joinRoom is needed</span>
+<span class="cm">// Optional — server auto-joins the room, but this is safe to keep</span>
 client.socket.<span class="fn">on</span>(<span class="str">'conversation_created'</span>, (conv) => {
-  client.socket.emit.<span class="fn">joinRoom</span>(conv.id);
+  client.socket.emit.<span class="fn">joinRoom</span>(conv.id); <span class="cm">// idempotent no-op if already joined</span>
 });</code></pre>
   </div>
   <div data-p="node">
@@ -1489,6 +1677,7 @@ client.socket.<span class="fn">on</span>(<span class="str">'new_message'</span>,
   client.socket.emit.<span class="fn">markRead</span>(message.conversationId, message.id);
 });
 
+<span class="cm">// Optional — server auto-joins the room, but safe to keep</span>
 client.socket.<span class="fn">on</span>(<span class="str">'conversation_created'</span>, (conv) => {
   client.socket.emit.<span class="fn">joinRoom</span>(conv.id);
 });</code></pre>
@@ -1498,7 +1687,7 @@ client.socket.<span class="fn">on</span>(<span class="str">'conversation_created
     <strong>Summary of rules:</strong>
     <ul>
       <li>All existing rooms are auto-joined on socket connect — no <code>joinRoom</code> needed on screen open.</li>
-      <li>Call <code>joinRoom</code> only after a <code>conversation_created</code> event.</li>
+      <li>When added to a conversation at runtime, the server now auto-joins the socket room and emits <code>conversation_created</code>. No <code>joinRoom</code> call needed, but safe to keep for compatibility.</li>
       <li>Add the <code>new_message</code> listener once at app root, never per screen.</li>
       <li>Use <code>message.conversationId</code> to route to the right view or badge update.</li>
       <li>Track <code>activeConversationId</code> to decide whether to increment the unread count.</li>
@@ -1957,11 +2146,11 @@ socket?.<span class="fn">on</span>(<span class="str">'read_receipt'</span>, ({ c
   <pre><code><span class="kw">await</span> socketEmit.<span class="fn">updateMessage</span>(messageId, <span class="str">'Updated text'</span>);
 <span class="cm">// REST fallback: await messagesApi.update(messageId, 'Updated text')</span></code></pre>
   <div class="callout info">
-    <strong>Edit window</strong> — check <code>conversation.settings.messageConfig.editWindowSeconds</code>:
+    <strong>Edit window</strong> — server default is <strong>900 s (15 minutes)</strong>. <code>conversation.settings.messageConfig.editWindowSeconds</code> is always populated — use it directly:
     <pre style="margin-top:8px"><code><span class="kw">function</span> <span class="fn">canEdit</span>(msg: <span class="tp">Message</span>, conv: <span class="tp">Conversation</span>, userId: <span class="tp">string</span>) {
   <span class="kw">if</span> (msg.senderId !== userId) <span class="kw">return false</span>;
-  <span class="kw">const</span> w = conv.settings?.messageConfig?.editWindowSeconds;
-  <span class="kw">return</span> !w || (Date.<span class="fn">now</span>() - <span class="kw">new</span> <span class="fn">Date</span>(msg.sentAt).<span class="fn">getTime</span>()) &lt; w * <span class="num">1000</span>;
+  <span class="kw">const</span> w = conv.settings?.messageConfig?.editWindowSeconds ?? <span class="num">900</span>;
+  <span class="kw">return</span> (Date.<span class="fn">now</span>() - <span class="kw">new</span> <span class="fn">Date</span>(msg.sentAt).<span class="fn">getTime</span>()) &lt; w * <span class="num">1000</span>;
 }</code></pre>
   </div>
 
@@ -1975,20 +2164,18 @@ socket?.<span class="fn">on</span>(<span class="str">'read_receipt'</span>, ({ c
   </table>
 
   <div class="callout info">
-    <strong>Default delete window</strong> — if <code>conversation.settings.messageConfig.deleteWindowSeconds</code> is not set, the server defaults to <strong>1800 seconds (30 minutes)</strong>. Your UI helper must use the same fallback, otherwise you may show "Delete for everyone" after the window has already expired on the server and get a <code>403 Forbidden</code> response.
+    <strong>Default delete window</strong> — server default is <strong>216,000 seconds (60 hours)</strong>. <code>conversation.settings.messageConfig.deleteWindowSeconds</code> is always populated — use it directly. Your UI helper must use the same fallback, otherwise you may show "Delete for everyone" after the window has already expired on the server and get a <code>403 Forbidden</code> response.
   </div>
 
   <div class="callout info">
     <strong>DMs have no admins</strong> — in a direct message conversation <code>conv.type === 'direct'</code>, participants have no <code>admin</code> role. <code>isAdmin</code> will always be <code>false</code>, so "Delete for everyone" is only available to the message sender within the window. Do not show an admin-based delete option in DMs.
   </div>
 
-  <pre><code><span class="kw">const</span> DEFAULT_DELETE_WINDOW_SEC = <span class="num">1800</span>; <span class="cm">// matches server default</span>
-
-<span class="kw">function</span> <span class="fn">getDeleteOptions</span>(msg: <span class="tp">Message</span>, conv: <span class="tp">Conversation</span>, userId: <span class="tp">string</span>) {
+  <pre><code><span class="kw">function</span> <span class="fn">getDeleteOptions</span>(msg: <span class="tp">Message</span>, conv: <span class="tp">Conversation</span>, userId: <span class="tp">string</span>) {
   <span class="kw">const</span> isMine    = msg.senderId === userId;
   <span class="kw">const</span> isAdmin   = conv.type !== <span class="str">'direct'</span> &&
                     conv.participants.<span class="fn">find</span>(p => p.userId === userId)?.role === <span class="str">'admin'</span>;
-  <span class="kw">const</span> w         = conv.settings?.messageConfig?.deleteWindowSeconds ?? DEFAULT_DELETE_WINDOW_SEC;
+  <span class="kw">const</span> w         = conv.settings?.messageConfig?.deleteWindowSeconds ?? <span class="num">216000</span>;
   <span class="kw">const</span> inWindow  = (Date.<span class="fn">now</span>() - <span class="kw">new</span> <span class="fn">Date</span>(msg.sentAt).<span class="fn">getTime</span>()) &lt; w * <span class="num">1000</span>;
   <span class="kw">return</span> { <span class="at">canDeleteForEveryone</span>: (isMine && inWindow) || isAdmin, <span class="at">canDeleteForMe</span>: <span class="kw">true</span> };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@antzsoft/chat-core",
-  "version": "1.0.9",
+  "version": "1.1.1",
   "description": "Platform-agnostic core for Antz Chat — API, socket, stores, types. Works in browser, React Native (Expo or bare), and Node.js.",
   "author": "Antz",
   "license": "MIT",