nodejs-insta-private-api-mqtt 1.3.16 → 1.3.17

package/README.md

@@ -292,7 +292,7 @@ There are two practical, compatible flows you can use depending on your client h
 2. Call the direct broadcast / configure_photo or configure_video HTTP endpoint to create the message server-side. MQTT will then deliver the server-created message to connected clients.  
    - Use this if you prefer to avoid relying on the realtime command to create messages.
 
-> Summary: **Always rupload via HTTP.** Then either broadcast via HTTP (configure endpoints) or publish an MQTT `send_item` referencing `upload_id`. MQTT does not carry the media bytes, only the reference.
+> Summary: **Always rupload via HTTP.** Then **use the HTTP configure/broadcast endpoints as the primary, reliable method** to attach media to threads. Publishing an MQTT `send_item` referencing `upload_id` may work as a best-effort fallback on some servers, but it is not guaranteed. MQTT never carries the raw media bytes, only metadata/reference.
 
 ---
 
@@ -422,7 +422,7 @@ await mqtt.publish({
   **A:** No — MQTT is not used for large raw bytes. The app uploads bytes via rupload HTTP.
 
 - **Q:** *If I publish the MQTT `send_item` with `upload_id`, will the message appear in the thread?*  
-  **A:** Yes — the realtime server accepts an MQTT `send_item` referencing a valid `upload_id`. The server will attempt to create/attach the media message and then propagate the message via MESSAGE_SYNC to other clients. The exact behavior can differ between server versions, so keep fallback to HTTP broadcast if reliability is essential.
+  **A:** Sometimes the realtime server accepts an MQTT `send_item` referencing a valid `upload_id`, but this behavior is not universally reliable across server versions, accounts, or configurations. For production reliability prefer the HTTP broadcast/configure endpoints; keep MQTT reference as a best-effort fallback.
 
 - **Q:** *Do I need to call `/direct_v2/threads/broadcast/...` if I published MQTT?*  
   **A:** Often not — the APK pattern uses MQTT for the attach request. However, for absolute compatibility or for older server behavior, the HTTP configure/broadcast endpoints are a safe fallback.
@@ -2197,27 +2197,49 @@ async function sendVideoAsMqttReference({ ig, mqtt, videoBuffer, threadId, capti
 
   const serverUploadId = (uploadResponse && uploadResponse.upload_id) ? uploadResponse.upload_id : uploadId;
 
-  // Publish MQTT reference
-  const clientContext = uuidv4();
-  const command = {
-    action: 'send_item',
-    thread_id: String(threadId),
-    item_type: 'media',
-    upload_id: serverUploadId,
-    text: caption || '',
-    client_context: clientContext,
-    timestamp: Date.now(),
-  };
-
-  const json = JSON.stringify(command);
-  const payload = await compressDeflate(json);
-  await mqtt.publish({
-    topic: constants.Topics.SEND_MESSAGE.id,
-    qosLevel: 1,
-    payload,
+  // ATTACH VIA HTTP BROADCAST (preferred, reliable)
+// Attempt REST broadcast first (most reliable). This will create the direct message server-side
+// and let MQTT/clients receive the created message as normal sync.
+try {
+  const broadcastResponse = await ig.request.send({
+    url: '/direct_v2/threads/broadcast/upload_photo/',
+    method: 'POST',
+    form: {
+      upload_id: serverUploadId,
+      action: 'send_item',
+      thread_ids: JSON.stringify([String(threadId)]),
+      caption: caption || '',
+      client_context: clientContext,
+    },
+    timeout: 60000,
   });
-
-  return { upload_id: serverUploadId };
+  return { upload_id: serverUploadId, broadcastResponse };
+} catch (err) {
+  // If REST broadcast fails for transient reasons, fall back to attempting an MQTT reference publish.
+  // NOTE: MQTT 'reference' publish is not guaranteed to be accepted on all server versions or accounts.
+  // Keep it as a fallback only — the HTTP broadcast above is the recommended, reliable method.
+  try {
+    const json = JSON.stringify({
+      action: 'send_item',
+      thread_id: String(threadId),
+      item_type: 'media',
+      upload_id: serverUploadId,
+      text: caption || '',
+      client_context: clientContext,
+      timestamp: Date.now(),
+    });
+    const payload = await compressDeflate(json);
+    await mqtt.publish({
+      topic: constants.Topics.SEND_MESSAGE.id,
+      qosLevel: 1,
+      payload,
+    });
+    return { upload_id: serverUploadId, mqttFallback: true };
+  } catch (err2) {
+    // last-resort: return upload id and both errors for debugging
+    return { upload_id: serverUploadId, broadcastError: err?.message || String(err), mqttError: err2?.message || String(err2) };
+  }
+}
 }
 ```
 
@@ -2268,10 +2290,6 @@ async function sendVideoViaRestBroadcast({ ig, videoBuffer, threadId, caption =
 }
 ```
 
-### FAQ notes
-- **Does MQTT send the file?** No — MQTT only transports the JSON reference (`upload_id`) telling the server to attach that already-uploaded file into the thread.
-- **Why use MQTT for reference instead of REST broadcast?** MQTT gives near-realtime messaging semantics; the server applies the `upload_id` to the thread (same result), but the heavy binary upload must be done via HTTP `rupload`.
-- **Can you skip rupload and only send MQTT?** No — server needs the binary available under the `upload_id`. If you send only MQTT without previously uploading, the server won't have the file to attach.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "nodejs-insta-private-api-mqtt",
-  "version": "1.3.16",
+  "version": "1.3.17",
   "description": "Complete Instagram MQTT protocol with FULL iOS + Android support. 33 device presets (21 iOS + 12 Android). iPhone 16/15/14/13/12, iPad Pro, Samsung, Pixel, Huawei. Real-time DM messaging, view-once media extraction, sub-500ms latency.",
   "main": "dist/index.js",
   "scripts": {