P2P WebSockets

ValorIDE can coordinate multiple IDE instances through a shared WebSocket protocol. The protocol is designed for agent-to-agent collaboration, remote command routing, and future swarm workflows.

Message Envelope

All peer messages use a consistent envelope:

{
  "sourceId": "ide-a",
  "targetId": "ide-b",
  "messageId": "01HV...",
  "type": "user_command",
  "payload": {},
  "timestamp": "2026-05-22T12:00:00.000Z"
}

Field	Purpose
`sourceId`	Sending ValorIDE instance
`targetId`	Receiving instance or `broadcast`
`messageId`	Unique message identifier for traceability
`type`	Payload discriminator
`payload`	Message-specific data
`timestamp`	ISO-8601 send time

Message Types

`user_command`

Injects a command into another ValorIDE instance as if the user had typed it.

{
  "taskId": null,
  "command": "Inspect the failing test and propose a fix.",
  "args": {}
}

`llm_response`

Broadcasts an assistant response or task update from one instance to its peers.

{
  "taskId": "task-123",
  "llmResponse": {
    "role": "assistant",
    "content": "The failing test is caused by..."
  }
}

Collaboration Flow

Implementation Notes

The protocol depends on three responsibilities:

A communication service sends, receives, validates, and routes envelopes.
The task or chat controller accepts inbound commands as controlled user input.
The LLM service emits response events when a remote-visible task completes or streams meaningful progress.

Safety Requirements

Remote command handling should be explicit and auditable:

validate source and target identities before dispatch
distinguish broadcast from direct command delivery
log message IDs with task IDs
require normal ValorIDE approval gates for file edits, shell commands, and external side effects

Related guides:

Message Envelope​

Message Types​

user_command​

llm_response​

Collaboration Flow​

Implementation Notes​

Safety Requirements​