Setting Up Peers

Pro Only

To set up peers, select Peers... from the Tasks tool's options menu in each Wing that will send or receive tasks. The project must be open in each, from a working copy of a Mercurial or Git repository with at least one commit. Setting up is naming this Wing, choosing the mailroom, and giving it the mailroom key. The dialog sets:

Peer Name -- The name other peers use for this Wing, such as mac or win-vm. A peer name belongs to one working copy, so two working copies on one machine need different names. The field suggests the machine's host name. Pressing OK with a name another Wing already has in the mailroom asks whether to take it over, as when moving a name to another working copy.
Machine Description -- One line that peers show for this Wing, such as Windows test box, so you and the Tasks Manager can choose which tasks to send it. By default this is empty.
Mailroom -- Either Local or Shared Folder and a full Path, or Directory on an ssh Remote Host, the host, and a Path on that host. See Choosing a Mailroom below. OK makes the mailroom if it is missing and the directory it is in exists.
Mailroom Key -- The key every peer in the mailroom shares. Press Generate on the first machine, then Copy, and Paste it into Peers... on each other machine. The key is kept once per mailroom on each machine, so every Wing there that uses the mailroom has it once it is entered in one. The text below the buttons shows the key's fingerprint. Peers stay off on a machine without a key.
Test Connection -- Saves the dialog, then checks that the mailroom can be reached and written and that this Wing's peer name is its own there. It lists each peer found, and says what needs fixing, such as a missing or different key or a peer whose Wing needs updating.
Peers in This Mailroom -- The peers found, with each one's description, operating system, branch, when it was last seen, and the version and build of Wing it runs. same repository marks each peer with a working copy of this repository. Wings that can't be peers, such as one with another key, are listed after them with the reason. Remove takes a peer that has not been seen for 10 minutes out of the mailroom.
Inbox Goal -- The goal on the Plan tab where tasks that peers send to this machine are filed. By default this is a new goal named Peer Requests. Select None: decline requests from peers for a machine that only sends tasks. File Tasks As sets whether these tasks are Ready, which is the default, or Draft, so they wait for you to read them and make them Ready.
Accept requests from other repositories -- Whether peers with other repositories can send this one reports and handoffs. This is checked by default.
Mark Complete closes the peer's copy too -- Whether marking a task that crossed machines complete here also completes its copy on the peer. This is checked by default. See Completing Tasks on Both Machines in Peer Task Details.

These settings are stored with the project, for this machine only. The mailroom key is kept in Wing's settings directory, readable only by your user account, and is never stored in a project file or in the mailroom. To leave a group of peers, clear the mailroom's Path.

Wing on each machine must be running, with the project open, to receive tasks. With the Tasks Manager on there, Ready tasks from peers run without anyone at that machine.

Choosing a Mailroom

Every peer must use the same mailroom. The mailroom can be any of these:

A shared folder -- A folder on one machine shared into virtual machines, or a share on a file server. Each machine gives the path as it sees it, for example /Users/me/WingMail on the host and Z:\WingMail on a Windows virtual machine.
A sync folder -- A folder kept in sync by Dropbox, OneDrive, iCloud Drive, Google Drive, or Syncthing. Messages arrive only as fast as the service syncs them. The service's provider can see peer names and when each peer is active, but can't read the tasks and changes.
A directory on an ssh host -- A directory on one of your Remote Hosts, which may be one of the peers or another machine. New... sets up a host. The path is on that host, either full or relative to the home directory there.

An ssh mailroom logs in as remote development does, with a key loaded into ssh-agent or a password or passphrase entered once in the Wing session. A machine that receives tasks with no one at it, such as a virtual machine after a restart, needs to log in without a prompt: load its key into ssh-agent at login, or give it a key with no passphrase that is authorized only on the mailroom's host. See Setting up SSH for Remote Development for details.

Who Can Send Tasks

Tasks from peers run with the receiving machine's agents and permissions, so keep the mailroom reachable only by your own machines, for example a folder shared only with your own virtual machines, or a directory on an ssh host that only you log into. Wing encrypts each message with the mailroom key, and a machine declines every message not encrypted with its key.

When two machines have different keys, or one has none, they decline each other's tasks, and the Send to Peer dialog says so. To fix it, copy one machine's key to the other. To remove a machine from the group, generate a new key and paste it on each machine that stays.

See Trust Peer Machines in AI Agent Safety for what a peer's task can and can't do on the receiving machine.