@decentnetwork/peer 0.1.19 → 0.1.21

package/dist/peer.js

@@ -188,6 +188,10 @@ export class Peer {
     // session entry exists yet so the connection loop does not flood DHT-PK
     // requests when route discovery keeps failing.
     #dhtPkSendCooldown = new Map();
+    // Per-friend cooldown for re-asserting the TCP-relay route toward an
+    // unconnected friend (the "accepted friend that never connects" wedge —
+    // requestRoute only fired once at startup and was never retried).
+    #routeRequestCooldown = new Map();
     // Per-friend consecutive "no routes available" count for DHT-PK so the
     // backoff grows if a friend stays unreachable, instead of retrying every
     // 25s forever for stale persisted entries.
@@ -719,7 +723,8 @@ export class Peer {
             address,
             nospam,
             hello: hello ?? existing?.hello,
-            status: existing?.status ?? "requested"
+            status: existing?.status ?? "requested",
+            requestedAt: existing?.requestedAt ?? Date.now()
         });
         this.#persistFriends();
         // Tell every connected TCP relay we want this friend routed; the
@@ -2387,6 +2392,29 @@ export class Peer {
             // nothing re-tried it. Counting the relay route lets the retry fire.
             const haveEndpoint = (friend.remoteHost && friend.remotePort) || session?.remote || session?.hasTcpRoute;
             if (!haveEndpoint) {
+                // No UDP endpoint AND no relay route yet. For a peer whose DHT
+                // self-announce never stored (WSL2, symmetric NAT, restrictive
+                // firewall), neither onion discovery nor UDP punch can ever find
+                // them — the ONLY bootstrap is the TCP relay: ask our relays to
+                // route to the friend's pubkey, and when they're also connected to
+                // a shared relay the pool fires `friendOnline` -> #initiateSession.
+                // requestRoute was only issued once at start(); if the friend or a
+                // relay wasn't connected in that instant it was never retried, so an
+                // accepted friend could sit at "requested" forever (the WSL-client-
+                // never-gets-an-IP bug). Re-assert it here on a cooldown — cheap and
+                // idempotent — so it eventually catches once both ends share a relay.
+                const lastRouteReq = this.#routeRequestCooldown.get(friendId) ?? 0;
+                if (this.#tcpRelays && now - lastRouteReq > 15_000) {
+                    try {
+                        const pk = base58ToBytes(friend.pubkey);
+                        if (pk.length === 32) {
+                            this.#tcpRelays.requestRoute(pk);
+                            this.#routeRequestCooldown.set(friendId, now);
+                            this.#debugLog(`re-requesting relay route for unconnected friend ${friendId}`);
+                        }
+                    }
+                    catch { /* skip malformed pubkey */ }
+                }
                 const dhtPk = session?.friendDhtPublicKey;
                 if (dhtPk) {
                     const found = await this.#discoverAndCacheFriendEndpoint(friendId, dhtPk).catch(() => false);

package/dist/store/friends.d.ts

@@ -9,5 +9,9 @@ export type FriendRecord = {
     remoteHost?: string;
     remotePort?: number;
     hello?: string;
+    /** When we sent the outbound friend request (ms epoch). Set once, even
+     *  while status stays "requested", so UIs can show how long a request
+     *  has been pending. */
+    requestedAt?: number;
     acceptedAt?: number;
 };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@decentnetwork/peer",
-  "version": "0.1.19",
+  "version": "0.1.21",
   "description": "Pure TypeScript port of Elastos Carrier (toxcore-derived) P2P messaging. DHT, onion routing, TCP relay, FlatBuffers app payloads, Express offline relay. Wire-compatible with iOS Beagle and the Carrier C SDK.",
   "type": "module",
   "main": "./dist/index.js",