v0.5.0 — WSS transport for CLI and daemon

Telegram login can now use WSS when a network closes raw MTProto TCP connections. Select it once at login; the profile remembers it for direct commands and daemon starts.

npm install -g @miolamio/tg-cli@0.5.0
tg --transport wss auth login --client desktop
tg daemon start --idle-timeout 0
tg daemon status
tg --daemon chat list --limit 5

Stop an existing daemon before upgrading or logging in. To use an existing session over WSS without logging in again, start it with tg --transport wss daemon start --idle-timeout 0.

• Add --transport tcp|wss; existing profiles default to TCP. Successful login/session import saves the selected transport.
• Use official Telegram DC hostnames and TLS with obfuscated MTProto framing, including DC migration and separate media connections. Saved session addresses are preserved.
• Bound and cancel pending WebSocket upgrades; isolate late callbacks from previous connections and keep error diagnostics free of raw payloads.
• Pass transport selection to foreground/background daemons and include it in daemon status. Proxied commands use the daemon's existing transport.

Validation: 1,302 tests across 102 files passed locally on Node 20 and Node 24; TypeScript checking and production build passed. Live Telegram checks on Node 20 covered a complete fresh key exchange, existing account authorization, a background WSS daemon, reading chats and Saved Messages, and subscription acknowledgement. No account messages were sent. The affected remote machine passed the anonymous WSS probe; a complete phone/code login there still needs confirmation.

WSS uses direct TLS connections and does not read HTTP_PROXY/HTTPS_PROXY. There is no automatic fallback to TCP.

The published npm archive was installed and smoke-tested on Node 20, 22, and 24, then downloaded from the registry and verified byte-for-byte. GitHub Actions run 34120363597 did not start its jobs because the GitHub account is locked due to a billing issue; local checks are not a passing CI run.