Skip to content

feat(whatsapp): add soft-thread sessions#16953

Closed
EvolvingSoftwareAgent wants to merge 1 commit into
NousResearch:mainfrom
EvolvingSoftwareAgent:feat/whatsapp-sessions-flat-replies
Closed

feat(whatsapp): add soft-thread sessions#16953
EvolvingSoftwareAgent wants to merge 1 commit into
NousResearch:mainfrom
EvolvingSoftwareAgent:feat/whatsapp-sessions-flat-replies

Conversation

@EvolvingSoftwareAgent

@EvolvingSoftwareAgent EvolvingSoftwareAgent commented Apr 28, 2026 •
edited
Loading

Copy link
Copy Markdown

Summary

  • Adds WhatsApp soft-thread session routing for flat reply surfaces.
  • Keeps each WhatsApp workstream as a normal Hermes session by assigning synthetic thread_id values in the adapter.
  • Routes quoted/replied-to WhatsApp messages back to the session that produced the quoted message.
  • Adds /sessions controls for listing, switching, and creating WhatsApp sessions.
  • Passes bridge-side quoted/reply metadata through to the gateway.
  • Documents WhatsApp session routing and adds gateway regression coverage.

How it works

  • WhatsApp chats are flat, so the adapter maintains a lightweight active-session map per chat/contact.
  • Unquoted messages continue in the current active WhatsApp session.
  • Replying to a Hermes WhatsApp message switches back to the session that produced that message, preserving the right context.
  • /sessions lists the active WhatsApp sessions for the chat.
  • /sessions new makes the next unquoted message use a fresh session.
  • /sessions new <message> creates a fresh session and sends <message> into it immediately.
  • /sessions <number> switches the current unquoted-message focus to one of the listed sessions.
  • Group gating still applies; session routing is layered on top of the existing WhatsApp authorization/mention behavior.

Current version

  • Refreshed onto current origin/main.
  • Current head: 02045915eac71eac57f9fa4684c18a6348cef6d7.
  • This version uses the /sessions UX and enable_sessions / session_idle_minutes / session_max_live_per_chat configuration names.

Test Plan

  • git diff --check origin/main...HEAD
  • scripts/run_tests.sh tests/gateway/test_whatsapp_sessions.py tests/gateway/test_whatsapp_group_gating.py -q — 41 passed

Refresh status

  • Rebased/updated for merge-conflict-free merge against current main.
  • Current head: 4fa28fc8b.
  • Mergeability verified via GitHub API: mergeable: true; mergeable_state: unstable because GitHub checks are pending/absent, not because of conflicts.
  • Notes: Rebased soft-thread WhatsApp session slice onto current main. No merge conflicts remain.
  • Test plan:
    • scripts/run_tests.sh tests/gateway/test_whatsapp_sessions.py tests/gateway/test_whatsapp_group_gating.py — 41 passed, 0 failed

@alt-glitch alt-glitch added type/feature New feature or request P2 Medium — degraded but workaround exists platform/whatsapp WhatsApp Business adapter comp/gateway Gateway runner, session dispatch, delivery labels Apr 28, 2026
@EvolvingSoftwareAgent EvolvingSoftwareAgent force-pushed the feat/whatsapp-sessions-flat-replies branch 2 times, most recently from 77c2c98 to 0204591 Compare May 17, 2026 01:30
@EvolvingSoftwareAgent EvolvingSoftwareAgent mentioned this pull request May 17, 2026
Open
2 tasks
@EvolvingSoftwareAgent EvolvingSoftwareAgent force-pushed the feat/whatsapp-sessions-flat-replies branch from 0204591 to 4fa28fc Compare May 27, 2026 09:09
@teknium1

teknium1 commented Jun 4, 2026

Copy link
Copy Markdown
Contributor

Thanks for this — the engineering here is genuinely clean. Mapping reply relationships onto synthetic source.thread_id values and riding the existing build_session_key machinery (rather than bolting on a new session subsystem) is exactly the right instinct, and the test coverage is solid (41 passing).

We're going to close it as a product decision, not a code-quality one.

The issue is the platform fit. WhatsApp's UX is a single flat stream — users don't think in "sessions," they just talk. This feature silently forks a chat into context-isolated lanes based on whether someone happened to tap "reply" on an older message, surfaces an unsolicited "🧵 New WhatsApp session started" notice, and exposes /sessions controls that assume a threads/tabs mental model the app itself doesn't provide. Telegram and Discord have real native threads, so thread→session mapping there is honest; on WhatsApp it invents invisible structure and asks the user to reason about it through reply-taps and slash commands. Being default-on means every existing WhatsApp user inherits that behavior change on upgrade.

If we revisit flat-platform sessions later, the bar would be opt-in and explicit-only: default off, no auto-fork on reply, no unsolicited notices, sessions created solely when a user runs /sessions new. Your implementation would be a strong starting point for that.

Appreciate the contribution and the care that went into it.

@teknium1 teknium1 closed this Jun 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

comp/gateway Gateway runner, session dispatch, delivery P2 Medium — degraded but workaround exists platform/whatsapp WhatsApp Business adapter type/feature New feature or request

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@EvolvingSoftwareAgent @teknium1 @alt-glitch