sway-ipc

package: swayfx

title: sway-ipc(7)

text:
# sway-ipc(7)

## NAME
sway-ipc - IPC protocol for sway

## DESCRIPTION
This details the interprocess communication (IPC) protocol for sway(1). This IPC protocol can be used to control or obtain information from a sway process.

The IPC protocol uses a UNIX socket as the method of communication. The path to the socket is stored in the environment variable SWAYSOCK and, for backwards compatibility with i3, I3SOCK. You can also retrieve the socket path by calling sway --get-socketpath.

## MESSAGE AND REPLY FORMAT
The format for messages and replies is:

<magic-string> <payload-length> <payload-type> <payload>

Where

<magic-string> is i3-ipc, for compatibility with i3

<payload-length> is a 32-bit integer in native byte order

<payload-type> is a 32-bit integer in native byte order For example, sending the exit command would look like the following hexdump:

```
00000000 | 69 33 2d 69 70 63 04 00 00 00 00 00 00 00 65 78 |i3-ipc........ex|
00000010 | 69 74                                           |it              |
```

The payload for replies will be a valid serialized JSON data structure.

## MESSAGES AND REPLIES
The following message types and their corresponding reply types are currently supported. For all replies, any properties not listed are subject to removal.

TYPE NUMBER

MESSAGE NAME

PURPOSE

0

RUN_COMMAND

Runs the payload as sway commands

1

GET_WORKSPACES

Get the list of current workspaces

2

SUBSCRIBE

Subscribe the IPC connection to the events listed in the payload

3

GET_OUTPUTS

Get the list of current outputs

4

GET_TREE

Get the node layout tree

5

GET_MARKS

Get the names of all the marks currently set

6

GET_BAR_CONFIG

Get the specified bar config or a list of bar config names

7

GET_VERSION

Get the version of sway that owns the IPC socket

8

GET_BINDING_MODES

Get the list of binding mode names

9

GET_CONFIG

Returns the config that was last loaded

10

SEND_TICK

Sends a tick event with the specified payload

11

SYNC

Replies failure object for i3 compatibility

12

GET_BINDING_STATE

Request the current binding state, e.g. the currently active binding mode name.

100

GET_INPUTS

Get the list of input devices

101

GET_SEATS

Get the list of seats

### 0. RUN_COMMAND
MESSAGE

Parses and runs the payload as sway commands

REPLY

An array of objects corresponding to each command that was parsed. Each object has the property success, which is a boolean indicating whether the command was successful. The object may also contain the properties error and parse_error. The error property is a human readable error message while parse_error is a boolean indicating whether the reason the command failed was because the command was unknown or not able to be parsed.

Example Reply:

```
[
	{
		"success": true
	},
	{
		"success": false,
		"parse_error": true,
		"error": "Invalid/unknown command"
	}
]
```

### 1. GET_WORKSPACES
MESSAGE

Retrieves the list of workspaces.

REPLY

The reply is an array of objects corresponding to each workspace. Each object has the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

num

integer

The workspace number or -1 for workspaces that do not start with a number

name

string

The name of the workspace

visible

boolean

Whether the workspace is currently visible on any output

focused

boolean

Whether the workspace is currently focused by the default seat (seat0)

urgent

boolean

Whether a window on the workspace has the urgent flag set

rect

object

The bounds of the workspace. It consists of x, y, width, and height

output

string

The name of the output that the workspace is on

Example Reply:

```
[
	{
		"num": 1,
		"name": "1",
		"visible": true,
		"focused": true,
		"rect": {
			"x": 0,
			"y": 23,
			"width": 1920,
			"height": 1057
		},
		"output": "eDP-1"
	},
]
```

### 2. SUBSCRIBE
MESSAGE

Subscribe this IPC connection to the event types specified in the message payload. The payload should be a valid JSON array of events. See the EVENTS section for the list of supported events.

REPLY

A single object that contains the property success, which is a boolean value indicating whether the subscription was successful or not.

Example Reply:

```
{
	"success": true
}
```

### 3. GET_OUTPUTS
MESSAGE

Retrieve the list of outputs

REPLY

An array of objects corresponding to each output. Each object has the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

name

string

The name of the output. On DRM, this is the connector

make

string

The make of the output

model

string

The model of the output

serial

string

The output's serial number as a hexadecimal string

active

boolean

Whether this output is active/enabled

dpms

boolean

(Deprecated, use power instead) Whether this output is on/off (via DPMS)

power

boolean

Whether this output is on/off

primary

boolean

For i3 compatibility, this will be false. It does not make sense in Wayland

scale

float

The scale currently in use on the output or -1 for disabled outputs

subpixel_hinting

string

The subpixel hinting current in use on the output. This can be rgb, bgr, vrgb, vbgr, or none

transform

string

The transform currently in use for the output. This can be normal, 90, 180, 270, flipped-90, flipped-180, or flipped-270

current_workspace

string

The workspace currently visible on the output or null for disabled outputs

modes

array

An array of supported mode objects. Each object contains width, height, and refresh

current_mode

object

An object representing the current mode containing width, height, and refresh

rect

object

The bounds for the output consisting of x, y, width, and height

Example Reply:

```
[
	{
		"name": "HDMI-A-2",
		"make": "Unknown",
		"model": "NS-19E310A13",
		"serial": "0x00000001",
		"active": true,
		"primary": false,
		"scale": 1.0,
		"subpixel_hinting": "rgb",
		"transform": "normal",
		"layer_shell_surfaces": [
			{
				"namespace": "wallpaper",
				"layer": "background",
				"extent": {
					"width": 2560,
					"height": 1440,
					"x": 0,
					"y": 0
				},
				"effects": {
				}
			},
			{
				"namespace": "waybar",
				"layer": "top",
				"extent": {
					"width": 2548,
					"height": 31,
					"x": 6,
					"y": 6
				},
				"effects": {
					"blur": true,
					"blur_xray": false,
					"blur_ignore_transparent": false,
					"shadows": true,
					"corner_radius": 20
				}
			}
		],
		"current_workspace": "1",
		"modes": [
			{
				"width": 640,
				"height": 480,
				"refresh": 59940
			},
			{
				"width": 800,
				"height": 600,
				"refresh": 60317
			},
			{
				"width": 1024,
				"height": 768,
				"refresh": 60004
			},
			{
				"width": 1920,
				"height": 1080,
				"refresh": 60000
			}
		],
		"current_mode": {
			"width": 1920,
			"height": 1080,
			"refresh": 60000
		}
	}
]
```

### 4. GET_TREE
MESSAGE

Retrieve a JSON representation of the tree

REPLY

An array of objects that represent the current tree. Each object represents one node and will have the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

id

integer

The internal unique ID for this node

name

string

The name of the node such as the output name or window title. For the scratchpad, this will be __i3_scratch for compatibility with i3.

type

string

The node type. It can be root, output, workspace, con, or floating_con

border

string

The border style for the node. It can be normal, none, pixel, or csd

current_border_width

integer

Number of pixels used for the border width

layout

string

The node's layout. It can either be splith, splitv, stacked, tabbed, or output

orientation

string

The node's orientation. It can be vertical, horizontal, or none

percent

float

The percentage of the node's parent that it takes up or null for the root and other special nodes such as the scratchpad

rect

object

The absolute geometry of the node. The window decorations are excluded from this, but borders are included.

window_rect

object

The geometry of the content inside the node. These coordinates are relative to the node itself. Window decorations and borders are outside the window_rect

deco_rect

object

The geometry of the decorations for the node relative to the parent node

geometry

object

The natural geometry of the contents if it were to size itself

urgent

boolean

Whether the node or any of its descendants has the urgent hint set. Note: This may not exist when compiled without xwayland support

sticky

boolean

Whether the node is sticky (shows on all workspaces)

marks

array

List of marks assigned to the node

focused

boolean

Whether the node is currently focused by the default seat (seat0)

focus

array

Array of child node IDs in the current focus order

nodes

array

The tiling children nodes for the node

floating_nodes

array

The floating children nodes for the node

representation

string

(Only workspaces) A string representation of the layout of the workspace that can be used as an aid in submitting reproduction steps for bug reports

fullscreen_mode

integer

(Only containers and windows) The fullscreen mode of the node. 0 means none, 1 means full workspace, and 2 means global fullscreen

floating

string

Floating state of container. Can be either "auto_off" or "user_on"

scratchpad_state

string

Whether the window is in the scratchpad. Can be either "none" or "fresh"

app_id

string

(Only windows) For an xdg-shell window, the name of the application, if set. Otherwise, null

pid

integer

(Only windows) The PID of the application that owns the window

foreign_toplevel_identifier

string

(Only windows) The ext-foreign-toplevel-list-v1 toplevel identifier of this node.

visible

boolean

(Only windows) Whether the node is visible

shell

string

(Only windows) The shell of the window, such as xdg_shell or xwayland

inhibit_idle

boolean

(Only windows) Whether the window is inhibiting the idle state

idle_inhibitors

object

(Only windows) An object containing the state of the application and user idle inhibitors. application can be enabled or none. user can be focus, fullscreen, open, visible or none.

sandbox_engine

string

(Only windows) The associated sandbox engine (or null)

sandbox_app_id

string

(Only windows) The app ID provided by the associated sandbox engine (or null)

sandbox_instance_id

string

(Only windows) The instance ID provided by the associated sandbox engine (or null)

window

integer

(Only xwayland windows) The X11 window ID for the xwayland window

window_properties

object

(Only xwayland windows) An object containing the title, class, instance, window_role, window_type, and transient_for for the window

Example Reply:

```
{
	"id": 1,
	"name": "root",
	"rect": {
		"x": 0,
		"y": 0,
		"width": 1920,
		"height": 1080
	},
	"focused": false,
	"focus": [
		3
	],
	"border": "none",
	"current_border_width": 0,
	"layout": "splith",
	"orientation": "horizontal",
	"percent": null,
	"window_rect": {
		"x": 0,
		"y": 0,
		"width": 0,
		"height": 0
	},
	"deco_rect": {
		"x": 0,
		"y": 0,
		"width": 0,
		"height": 0
	},
	"geometry": {
		"x": 0,
		"y": 0,
		"width": 0,
		"height": 0
	},
	"window": null,
	"urgent": false,
	"floating_nodes": [
	],
	"sticky": false,
	"type": "root",
	"nodes": [
		{
			"id": 2147483647,
			"name": "__i3",
			"rect": {
				"x": 0,
				"y": 0,
				"width": 1920,
				"height": 1080
			},
			"focused": false,
			"focus": [
				2147483646
			],
			"border": "none",
			"current_border_width": 0,
			"layout": "output",
			"orientation": "horizontal",
			"percent": null,
			"window_rect": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"deco_rect": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"geometry": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"window": null,
			"urgent": false,
			"floating_nodes": [
			],
			"sticky": false,
			"type": "output",
			"nodes": [
				{
					"id": 2147483646,
					"name": "__i3_scratch",
					"rect": {
						"x": 0,
						"y": 0,
						"width": 1920,
						"height": 1080
					},
					"focused": false,
					"focus": [
					],
					"border": "none",
					"current_border_width": 0,
					"layout": "splith",
					"orientation": "horizontal",
					"percent": null,
					"window_rect": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"deco_rect": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"geometry": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"window": null,
					"urgent": false,
					"floating_nodes": [
					],
					"sticky": false,
					"type": "workspace"
				}
			]
		},
		{
			"id": 3,
			"name": "eDP-1",
			"rect": {
				"x": 0,
				"y": 0,
				"width": 1920,
				"height": 1080
			},
			"focused": false,
			"focus": [
				4
			],
			"border": "none",
			"current_border_width": 0,
			"layout": "output",
			"orientation": "none",
			"percent": 1.0,
			"window_rect": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"deco_rect": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"geometry": {
				"x": 0,
				"y": 0,
				"width": 0,
				"height": 0
			},
			"window": null,
			"urgent": false,
			"floating_nodes": [
			],
			"sticky": false,
			"type": "output",
			"active": true,
			"primary": false,
			"make": "Unknown",
			"model": "0x38ED",
			"serial": "0x00000000",
			"scale": 1.0,
			"transform": "normal",
			"current_workspace": "1",
			"modes": [
				{
					"width": 1920,
					"height": 1080,
					"refresh": 60052
				}
			],
			"current_mode": {
				"width": 1920,
				"height": 1080,
				"refresh": 60052
			},
			"nodes": [
				{
					"id": 4,
					"name": "1",
					"rect": {
						"x": 0,
						"y": 23,
						"width": 1920,
						"height": 1057
					},
					"focused": false,
					"focus": [
						6,
						5
					],
					"border": "none",
					"current_border_width": 0,
					"layout": "splith",
					"orientation": "horizontal",
					"percent": null,
					"window_rect": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"deco_rect": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"geometry": {
						"x": 0,
						"y": 0,
						"width": 0,
						"height": 0
					},
					"window": null,
					"urgent": false,
					"floating_nodes": [
					],
					"sticky": false,
					"num": 1,
					"output": "eDP-1",
					"type": "workspace",
					"representation": "H[URxvt termite]",
					"nodes": [
						{
							"id": 5,
							"name": "urxvt",
							"rect": {
								"x": 0,
								"y": 23,
								"width": 960,
								"height": 1057
							},
							"focused": false,
							"focus": [
							],
							"border": "normal",
							"current_border_width": 2,
							"layout": "none",
							"orientation": "none",
							"percent": 0.5,
							"window_rect": {
								"x": 2,
								"y": 0,
								"width": 956,
								"height": 1030
							},
							"deco_rect": {
								"x": 0,
								"y": 0,
								"width": 960,
								"height": 25
							},
							"geometry": {
								"x": 0,
								"y": 0,
								"width": 1124,
								"height": 422
							},
							"window": 4194313,
							"urgent": false,
							"floating_nodes": [
							],
							"sticky": false,
							"type": "con",
							"fullscreen_mode": 0,
							"pid": 23959,
							"app_id": null,
							"visible": true,
							"shell": "xwayland",
							"inhibit_idle": true,
							"idle_inhibitors": {
								"application": "none",
								"user": "visible",
							},
							"window_properties": {
								"class": "URxvt",
								"instance": "urxvt",
								"title": "urxvt",
								"transient_for": null
							},
							"nodes": [
							]
						},
						{
							"id": 6,
							"name": "",
							"rect": {
								"x": 960,
								"y": 23,
								"width": 960,
								"height": 1057
							},
							"focused": true,
							"focus": [
							],
							"border": "normal",
							"current_border_width": 2,
							"layout": "none",
							"orientation": "none",
							"percent": 0.5,
							"window_rect": {
								"x": 2,
								"y": 0,
								"width": 956,
								"height": 1030
							},
							"deco_rect": {
								"x": 0,
								"y": 0,
								"width": 960,
								"height": 25
							},
							"geometry": {
								"x": 0,
								"y": 0,
								"width": 817,
								"height": 458
							},
							"window": null,
							"urgent": false,
							"floating_nodes": [
							],
							"sticky": false,
							"type": "con",
							"fullscreen_mode": 0,
							"pid": 25370,
							"app_id": "termite",
							"visible": true,
							"shell": "xdg_shell",
							"inhibit_idle": false,
							"idle_inhibitors": {
								"application": "none",
								"user": "fullscreen",
							},
							"nodes": [
							]
						}
					]
				}
			]
		}
	]
}
```

### 5. GET_MARKS
MESSAGE

Retrieve the currently set marks

REPLY

An array of marks current set. Since each mark can only be set for one container, this is a set so each value is unique and the order is undefined.

Example Reply:

```
[
	"one",
	"test"
]
```

### 6. GET_BAR_CONFIG (WITHOUT A PAYLOAD)
MESSAGE

When sending without a payload, this retrieves the list of configured bar IDs

REPLY

An array of bar IDs, which are strings

Example Reply:

```
[
	"bar-0",
	"bar-1"
]
```

### 6. GET_BAR_CONFIG (WITH A PAYLOAD)
MESSAGE

When sent with a bar ID as the payload, this retrieves the config associated with the specified by the bar ID in the payload. This is used by swaybar, but could also be used for third party bars

REPLY

An object that represents the configuration for the bar with the bar ID sent as the payload. The following properties exists and more information about what their value mean can be found in sway-bar(5):

PROPERTY

DATA TYPE

DESCRIPTION

id

string

The bar ID

mode

string

The mode for the bar. It can be dock, hide, or invisible

position

string

The bar's position. It can currently either be bottom or top

status_command

string

The command which should be run to generate the status line

font

string

The font to use for the text on the bar

workspace_buttons

boolean

Whether to display the workspace buttons on the bar

workspace_min_width

integer

Minimum width in px for the workspace buttons on the bar

binding_mode_indicator

boolean

Whether to display the current binding mode on the bar

verbose

boolean

For i3 compatibility, this will be the boolean value false.

colors

object

An object containing the #RRGGBBAA colors to use for the bar. See below for more information

gaps

object

An object representing the gaps for the bar consisting of top, right, bottom, and left.

bar_height

integer

The absolute height to use for the bar or 0 to automatically size based on the font

status_padding

integer

The vertical padding to use for the status line

status_edge_padding

integer

The horizontal padding to use for the status line when at the end of an output

The colors object contains the following properties, which are all strings containing the #RRGGBBAA representation of the color:

PROPERTY

DESCRIPTION

background

The color to use for the bar background on unfocused outputs

statusline

The color to use for the status line text on unfocused outputs

separator

The color to use for the separator text on unfocused outputs

focused_background

The color to use for the background of the bar on the focused output

focused_statusline

The color to use for the status line text on the focused output

focused_separator

The color to use for the separator text on the focused output

focused_workspace_text

The color to use for the text of the focused workspace button

focused_workspace_bg

The color to use for the background of the focused workspace button

focused_workspace_border

The color to use for the border of the focused workspace button

active_workspace_text

The color to use for the text of the workspace buttons for the visible workspaces on unfocused outputs

active_workspace_bg

The color to use for the background of the workspace buttons for the visible workspaces on unfocused outputs

active_workspace_border

The color to use for the border of the workspace buttons for the visible workspaces on unfocused outputs

inactive_workspace_text

The color to use for the text of the workspace buttons for workspaces that are not visible

inactive_workspace_bg

The color to use for the background of the workspace buttons for workspaces that are not visible

inactive_workspace_border

The color to use for the border of the workspace buttons for workspaces that are not visible

urgent_workspace_text

The color to use for the text of the workspace buttons for workspaces that contain an urgent window

urgent_workspace_bg

The color to use for the background of the workspace buttons for workspaces that contain an urgent window

urgent_workspace_border

The color to use for the border of the workspace buttons for workspaces that contain an urgent window

binding_mode_text

The color to use for the text of the binding mode indicator

binding_mode_bg

The color to use for the background of the binding mode indicator

binding_mode_border

The color to use for the border of the binding mode indicator

Example Reply:

```
{
	"id": "bar-0",
	"mode": "dock",
	"position": "top",
	"status_command": "while date +'%Y-%m-%d %l:%M:%S %p'; do sleep 1; done",
	"font": "monospace 10",
	"gaps": {
		"top": 0,
		"right": 0,
		"bottom": 0,
		"left": 0
	},
	"bar_height": 0,
	"status_padding": 1,
	"status_edge_padding": 3,
	"workspace_buttons": true,
	"workspace_min_width": 0,
	"binding_mode_indicator": true,
	"verbose": false,
	"pango_markup": false,
	"colors": {
		"background": "#323232ff",
		"statusline": "#ffffffff",
		"separator": "#666666ff",
		"focused_background": "#323232ff",
		"focused_statusline": "#ffffffff",
		"focused_separator": "#666666ff",
		"focused_workspace_border": "#4c7899ff",
		"focused_workspace_bg": "#285577ff",
		"focused_workspace_text": "#ffffffff",
		"inactive_workspace_border": "#32323200",
		"inactive_workspace_bg": "#32323200",
		"inactive_workspace_text": "#5c5c5cff",
		"active_workspace_border": "#333333ff",
		"active_workspace_bg": "#5f676aff",
		"active_workspace_text": "#ffffffff",
		"urgent_workspace_border": "#2f343aff",
		"urgent_workspace_bg": "#900000ff",
		"urgent_workspace_text": "#ffffffff",
		"binding_mode_border": "#2f343aff",
		"binding_mode_bg": "#900000ff",
		"binding_mode_text": "#ffffffff"
	},
}
```

### 7. GET_VERSION
MESSAGE

Retrieve version information about the sway process

REPLY

An object containing the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

major

integer

The major version of the sway process

minor

integer

The minor version of the sway process

patch

integer

The patch version of the sway process

human_readable

string

A human readable version string that will likely contain more useful information such as the git commit short hash and git branch

loaded_config_file_name

string

The path to the loaded config file

Example Reply:

```
{
	"human_readable": "1.0-rc1-117-g2f7247e0 (Feb 24 2019, branch 'master')",
	"major": 1,
	"minor": 0,
	"patch": 0,
	"loaded_config_file_name": "/home/redsoxfan/.config/sway/config"
}
```

### 8. GET_BINDING_MODES
MESSAGE

Retrieve the list of binding modes that currently configured

REPLY

An array of strings, with each string being the name of a binding mode. This will always contain at least one mode (currently default), which is the default binding mode

Example Reply:

```
[
	"default",
	"resize",
]
```

### 9. GET_CONFIG
MESSAGE

Retrieve the contents of the config that was last loaded

REPLY

An object with a single string property containing the contents of the config

Example Reply:

```
{
	"config": "set $mod Mod4\nbindsym $mod+q exit\n"
}
```

### 10. SEND_TICK
MESSAGE

Issues a TICK event to all clients subscribing to the event to ensure that all events prior to the tick were received. If a payload is given, it will be included in the TICK event

REPLY

A single object contains the property success, which is a boolean value indicating whether the TICK event was sent.

Example Reply:

```
{
	"success": true
}
```

### 11. SYNC
MESSAGE

For i3 compatibility, this command will just return a failure object since it does not make sense to implement in sway due to the X11 nature of the command. If you are curious about what this IPC command does in i3, refer to the i3 documentation.

REPLY

A single object that contains the property success, which is set to the boolean value false.

Exact Reply:

```
{
	"success": false
}
```

### 12. GET_BINDING_STATE
MESSAGE

Returns the currently active binding mode.

REPLY

A single object that contains the property name, which is set to the currently active binding mode as a string.

Exact Reply:

```
{
	"name": "default"
}
```

### 100. GET_INPUTS
MESSAGE

Retrieve a list of the input devices currently available

REPLY

An array of objects corresponding to each input device. Each object has the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

identifier

string

The identifier for the input device

name

string

The human readable name for the device

vendor

integer

The vendor code for the input device

product

integer

The product code for the input device

type

string

The device type. Currently this can be keyboard, pointer, touch, tablet_tool, tablet_pad, or switch

xkb_active_layout_name

string

(Only keyboards) The name of the active keyboard layout in use

xkb_layout_names

array

(Only keyboards) A list a layout names configured for the keyboard

xkb_active_layout_index

integer

(Only keyboards) The index of the active keyboard layout in use

scroll_factor

floating

(Only pointers) Multiplier applied on scroll event values.

libinput

object

(Only libinput devices) An object describing the current device settings. See below for more information

The libinput object describes the device configuration for libinput devices. Only properties that are supported for the device will be added to the object. In addition to the possible options listed, all string properties may also be unknown, in the case that a new option is added to libinput. See sway-input(5) for information on the meaning of the possible values. The following properties will be included for devices that support them:

PROPERTY

DATA TYPE

DESCRIPTION

send_events

string

Whether events are being sent by the device. It can be enabled, disabled, or disabled_on_external_mouse

tap

string

Whether tap to click is enabled. It can be enabled or disabled

tap_button_map

string

The finger to button mapping in use for tapping. It can be lmr or lrm

tap_drag

string

Whether tap-and-drag is enabled. It can be enabled or disabled

tap_drag_lock

string

Whether drag-lock is enabled. It can be enabled, disabled or enabled_sticky

accel_speed

double

The pointer-acceleration in use

accel_profile

string

The acceleration profile in use. It can be none, flat, or adaptive

natural_scroll

string

Whether natural scrolling is enabled. It can be enabled or disabled

left_handed

string

Whether left-handed mode is enabled. It can be enabled or disabled

click_method

string

The click method in use. It can be none, button_areas, or clickfinger

click_button_map

string

The finger to button mapping in use for clickfinger. It can be lmr or lrm

middle_emulation

string

Whether middle emulation is enabled. It can be enabled or disabled

scroll_method

string

The scroll method in use. It can be none, two_finger, edge, or on_button_down

scroll_button

int

The scroll button to use when scroll_method is on_button_down. This will be given as an input event code

scroll_button_lock

string

Whether scroll button lock is enabled. It can be enabled or disabled

dwt

string

Whether disable-while-typing is enabled. It can be enabled or disabled

dwtp

string

Whether disable-while-trackpointing is enabled. It can be enabled or_disabled_

calibration_matrix

array

An array of 6 floats representing the calibration matrix for absolute devices such as touchscreens

Example Reply:

```
[
	{
		"identifier": "1:1:AT_Translated_Set_2_keyboard",
		"name": "AT Translated Set 2 keyboard",
		"vendor": 1,
		"product": 1,
		"type": "keyboard",
		"xkb_active_layout_name": "English (US)",
		"libinput": {
			"send_events": "enabled"
		}
	},
	{
		"identifier": "1267:5:Elan_Touchpad",
		"name": "Elan Touchpad",
		"vendor": 1267,
		"product": 5,
		"type": "pointer",
		"libinput": {
			"send_events": "enabled",
			"tap": "enabled",
			"tap_button_map": "lmr",
			"tap_drag": "enabled",
			"tap_drag_lock": "disabled",
			"accel_speed": 0.0,
			"accel_profile": "none",
			"natural_scroll", "disabled",
			"left_handed": "disabled",
			"click_method": "button_areas",
			"middle_emulation": "disabled",
			"scroll_method": "edge",
			"dwt": "enabled",
			"dwtp": "enabled"
		}
	},
	{
		"identifier": "3034:22494:USB2.0_VGA_UVC_WebCam:_USB2.0_V",
		"name": "USB2.0 VGA UVC WebCam: USB2.0 V",
		"vendor": 3034,
		"product": 22494,
		"type": "keyboard",
		"xkb_active_layout_name": "English (US)",
		"libinput": {
			"send_events": "enabled"
		}
	},
	{
		"identifier": "0:3:Sleep_Button",
		"name": "Sleep Button",
		"vendor": 0,
		"product": 3,
		"type": "keyboard",
		"xkb_active_layout_name": "English (US)",
		"libinput": {
			"send_events": "enabled"
		}
	},
	{
		"identifier": "0:5:Lid_Switch",
		"name": "Lid Switch",
		"vendor": 0,
		"product": 5,
		"type": "switch",
		"libinput": {
			"send_events": "enabled"
		}
	},
	{
		"identifier": "0:6:Video_Bus",
		"name": "Video Bus",
		"vendor": 0,
		"product": 6,
		"type": "keyboard",
		"xkb_active_layout_name": "English (US)",
		"libinput": {
			"send_events": "enabled"
		}
	},
	{
		"identifier": "0:1:Power_Button",
		"name": "Power Button",
		"vendor": 0,
		"product": 1,
		"type": "keyboard",
		"xkb_active_layout_name": "English (US)",
		"libinput": {
			"send_events": "enabled"
		}
	}
]
```

### 101. GET_SEATS
MESSAGE

Retrieve a list of the seats currently configured

REPLY

An array of objects corresponding to each seat. There will always be at least one seat. Each object has the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

name

string

The unique name for the seat

capabilities

integer

The number of capabilities that the seat has

focus

integer

The id of the node currently focused by the seat or 0 when the seat is not currently focused by a node (i.e. a surface layer or xwayland unmanaged has focus)

devices

array

An array of input devices that are attached to the seat. Currently, this is an array of objects that are identical to those returned by GET_INPUTS

Example Reply:

```
[
	{
		"name": "seat0",
		"capabilities": 3,
		"focus": 7,
		"devices": [
			{
				"identifier": "1:1:AT_Translated_Set_2_keyboard",
				"name": "AT Translated Set 2 keyboard",
				"vendor": 1,
				"product": 1,
				"type": "keyboard",
				"xkb_active_layout_name": "English (US)",
				"libinput": {
					"send_events": "enabled"
				}
			},
			{
				"identifier": "1267:5:Elan_Touchpad",
				"name": "Elan Touchpad",
				"vendor": 1267,
				"product": 5,
				"type": "pointer",
				"libinput": {
					"send_events": "enabled",
					"tap": "enabled",
					"tap_button_map": "lmr",
					"tap_drag": "enabled",
					"tap_drag_lock": "disabled",
					"accel_speed": 0.0,
					"accel_profile": "none",
					"natural_scroll", "disabled",
					"left_handed": "disabled",
					"click_method": "button_areas",
					"middle_emulation": "disabled",
					"scroll_method": "edge",
					"dwt": "enabled",
					"dwtp": "enabled"
				}
			},
			{
				"identifier": "3034:22494:USB2.0_VGA_UVC_WebCam:_USB2.0_V",
				"name": "USB2.0 VGA UVC WebCam: USB2.0 V",
				"vendor": 3034,
				"product": 22494,
				"type": "keyboard",
				"xkb_active_layout_name": "English (US)",
				"libinput": {
					"send_events": "enabled"
				}
			},
			{
				"identifier": "0:3:Sleep_Button",
				"name": "Sleep Button",
				"vendor": 0,
				"product": 3,
				"type": "keyboard",
				"xkb_active_layout_name": "English (US)",
				"libinput": {
					"send_events": "enabled"
				}
			},
			{
				"identifier": "0:5:Lid_Switch",
				"name": "Lid Switch",
				"vendor": 0,
				"product": 5,
				"type": "switch",
				"libinput": {
					"send_events": "enabled"
				}
			},
			{
				"identifier": "0:6:Video_Bus",
				"name": "Video Bus",
				"vendor": 0,
				"product": 6,
				"type": "keyboard",
				"xkb_active_layout_name": "English (US)",
				"libinput": {
					"send_events": "enabled"
				}
			},
			{
				"identifier": "0:1:Power_Button",
				"name": "Power Button",
				"vendor": 0,
				"product": 1,
				"type": "keyboard",
				"xkb_active_layout_name": "English (US)",
				"libinput": {
					"send_events": "enabled"
				}
			}
		]
	}
]
```

## EVENTS
Events are a way for client to get notified of changes to sway. A client can subscribe to any events it wants to be notified of changes for. The event is sent in the same format as a reply. The following events are currently available:

EVENT TYPE

NAME

DESCRIPTION

0x80000000

workspace

Sent whenever an event involving a workspace occurs such as initialization of a new workspace or a different workspace gains focus

0x80000001

output

Sent when outputs are updated

0x80000002

mode

Sent whenever the binding mode changes

0x80000003

window

Sent whenever an event involving a window occurs such as being reparented, focused, or closed

0x80000004

barconfig_update

Sent whenever a bar config changes

0x80000005

binding

Sent when a configured binding is executed

0x80000006

shutdown

Sent when the ipc shuts down because sway is exiting

0x80000007

tick

Sent when an ipc client sends a SEND_TICK message

0x80000014

bar_state_update

Send when the visibility of a bar should change due to a modifier

0x80000015

input

Sent when something related to input devices changes

### 0x80000000. WORKSPACE
Sent whenever a change involving a workspace occurs. The event consists of a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

change

string

The type of change that occurred. See below for more information

current

object

An object representing the workspace effected or null for reload changes

old

object

For a focus change, this is will be an object representing the workspace being switched from. Otherwise, it is null

The following change types are currently available:

TYPE

DESCRIPTION

init

The workspace was created

empty

The workspace is empty and is being destroyed since it is not visible

focus

The workspace was focused. See the old property for the previous focus

move

The workspace was moved to a different output

rename

The workspace was renamed

urgent

A window on the workspace has had their urgency hint set or all urgency hints for windows on the workspace have been cleared

reload

The configuration file has been reloaded

Example Event:

```
{
	"change": "init",
	"old": null,
	"current": {
		"id": 10,
		"name": "2",
		"rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"focused": false,
		"focus": [
		],
		"border": "none",
		"current_border_width": 0,
		"layout": "splith",
		"percent": null,
		"window_rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"deco_rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"geometry": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"window": null,
		"urgent": false,
		"floating_nodes": [
		],
		"num": 2,
		"output": "eDP-1",
		"type": "workspace",
		"representation": null,
		"nodes": [
		]
	}
}
```

### 0x80000001. OUTPUT
Sent whenever an output is added, removed, or its configuration is changed. The event is a single object with the property change, which is a string containing the reason for the change. Currently, the only value for change is unspecified.

Example Event:

```
{
	"change": "unspecified"
}
```

### 0x80000002. MODE
Sent whenever the binding mode changes. The event consists of a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

change

string

The binding mode that became active

pango_markup

boolean

Whether the mode should be parsed as pango markup

Example Event:

```
{
	"change": "default",
	"pango_markup": false
}
```

### 0x80000003. WINDOW
Sent whenever a change involving a window occurs. The event consists of a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

change

string

The type of change that occurred. See below for more information

container

object

An object representing the window effected

The following change types are currently available:

TYPE

DESCRIPTION

new

The window was created

close

The window was closed

focus

The window was focused

title

The window's title has changed

fullscreen_mode

The window's fullscreen mode has changed

move

The window has been reparented in the tree

floating

The window has become floating or is no longer floating

urgent

The window's urgency hint has changed status

mark

A mark has been added or removed from the window

Example Event:

```
{
	"change": "new",
	"container": {
		"id": 12,
		"name": null,
		"rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"focused": false,
		"focus": [
		],
		"border": "none",
		"current_border_width": 0,
		"layout": "none",
		"percent": 0.0,
		"window_rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"deco_rect": {
			"x": 0,
			"y": 0,
			"width": 0,
			"height": 0
		},
		"geometry": {
			"x": 0,
			"y": 0,
			"width": 1124,
			"height": 422
		},
		"window": 4194313,
		"urgent": false,
		"floating_nodes": [
		],
		"type": "con",
		"pid": 19787,
		"app_id": null,
		"window_properties": {
			"class": "URxvt",
			"instance": "urxvt",
			"transient_for": null
		},
		"nodes": [
		]
	}
}
```

### 0x80000004. BARCONFIG_UPDATE
Sent whenever a config for a bar changes. The event is identical to that of GET_BAR_CONFIG when a bar ID is given as a payload. See 6. GET_BAR_CONFIG (WITH A PAYLOAD) above for more information.

### 0x80000005. BINDING
Sent whenever a binding is executed. The event is a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

change

string

The change that occurred for the binding. Currently this will only be run

command

string

The command associated with the binding

event_state_mask

array

An array of strings that correspond to each modifier key for the binding

input_code

integer

For keyboard bindcodes, this is the key code for the binding. For mouse bindings, this is the X11 button number, if there is an equivalent. In all other cases, this will be 0.

symbol

string

For keyboard bindsyms, this is the bindsym for the binding. Otherwise, this will be null

input_type

string

The input type that triggered the binding. This is either keyboard or mouse

Example Event:

```
{
	"change": "run",
	"binding": {
		"command": "workspace 2",
		"event_state_mask": [
			"Mod4"
		],
		"input_code": 0,
		"symbol": "2",
		"input_type": "keyboard"
	}
}
```

### 0x80000006. SHUTDOWN
Sent whenever the IPC is shutting down. The event is a single object with the property change, which is a string containing the reason for the shutdown. Currently, the only value for change is exit, which is issued when sway is exiting.

Example Event:

```
{
	"change": "exit"
}
```

### 0x80000007. TICK
Sent when first subscribing to tick events or by a SEND_TICK message. The event is a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

first

boolean

Whether this event was triggered by subscribing to the tick events

payload

string

The payload given with a SEND_TICK message, if any. Otherwise, an empty string

Example Event:

```
{
	"first": true
	"payload": ""
}
```

### 0x80000014. BAR_STATE_UPDATE
Sent when the visibility of a bar changes due to a modifier being pressed. The event is a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

id

string

The bar ID effected

visible_by_modifier

boolean

Whether the bar should be made visible due to a modifier being pressed

Example Event:

```
{
	"id": "bar-0",
	"visible_by_modifier": true
}
```

### 0x80000015. INPUT
Sent when something related to the input devices changes. The event is a single object with the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

change

string

What has changed

input

object

An object representing the input that is identical the ones GET_INPUTS gives

The following change types are currently available:

TYPE

DESCRIPTION

added

The input device became available

removed

The input device is no longer available

xkb_keymap

(Keyboards only) The keymap for the keyboard has changed

xkb_layout

(Keyboards only) The effective layout in the keymap has changed

libinput_config

(libinput device only) A libinput config option for the device changed

Example Event:

```
{
	"change": "xkb_layout",
	"input": {
		"identifier": "1:1:AT_Translated_Set_2_keyboard",
		"name": "AT Translated Set 2 keyboard",
		"vendor": 1,
		"product": 1,
		"type": "keyboard",
		"xkb_layout_names": [
			"English (US)",
			"English (Dvorak)"
		],
		"xkb_active_layout_index": 1,
		"xkb_active_layout_name": "English (Dvorak)",
		"libinput": {
			"send_events": "enabled"
		}
	}
}
```

## SEE ALSO
sway(1) sway(5) sway-bar(5) swaymsg(1) sway-input(5) sway-output(5)


swaybar-protocol

title: swaybar-protocol(7)

text:
# swaybar-protocol(7)

## NAME
swaybar-protocol - JSON status line protocol for swaybar

## SUMMARY
swaybar defines the following JSON protocol to specify what information is displayed in the status line on the right side of swaybar. The protocol comprises a header, that is a JSON object, followed by a newline (0x0A), followed by an infinite JSON array that represents the information to display. All communication is done by writing the status line to standard output and reading events from standard input.

## HEADER
The header is a JSON object with support for the following properties (only version is required):

PROPERTY

DATA TYPE

DEFAULT

DESCRIPTION

version

integer

-

The protocol version to use. Currently, this must be 1

click_events

boolean

false

Whether to receive click event information to standard input

cont_signal

integer

SIGCONT

The signal that swaybar should send to continue processing

stop_signal

integer

SIGSTOP

The signal that swaybar should send to stop processing

### MINIMAL HEADER

```
{
	"version": 1
}
```

### FULL HEADER

```
{
	"version": 1,
	"click_events": true,
	"cont_signal": 18,
	"stop_signal": 19
}
```

## BODY
The body is an infinite array, where each element of the array is a representation of the status line at the time that the element was written. Each element of the array is itself an array of JSON objects, where each object represents a block in the status line. Each block can have the following properties (only full_text is required):

PROPERTY

DATA TYPE

DESCRIPTION

full_text

string

The text that will be displayed. If missing, the block will be skipped.

short_text

string

If given and the text needs to be shortened due to space, this will be displayed instead of full_text

color

string

The text color to use in #RRGGBBAA or #RRGGBB notation

background

string

The background color for the block in #RRGGBBAA or #RRGGBB notation

border

string

The border color for the block in #RRGGBBAA or #RRGGBB notation

border_top

integer

The height in pixels of the top border. The default is 1

border_bottom

integer

The height in pixels of the bottom border. The default is 1

border_left

integer

The width in pixels of the left border. The default is 1

border_right

integer

The width in pixels of the right border. The default is 1

min_width

integer or string

The minimum width to use for the block. This can either be given in pixels or a string can be given to allow for it to be calculated based on the width of the string.

align

string

If the text does not span the full width of the block, this specifies how the text should be aligned inside of the block. This can be left (default), right, or center.

name

string

A name for the block. This is only used to identify the block for click events. If set, each block should have a unique name and instance pair.

instance

string

The instance of the name for the block. This is only used to identify the block for click events. If set, each block should have a unique name and instance pair.

urgent

boolean

Whether the block should be displayed as urgent. Currently swaybar utilizes the colors set in the sway config for urgent workspace buttons. See sway-bar(5) for more information on bar color configuration.

separator

boolean

Whether the bar separator should be drawn after the block. See sway-bar(5) for more information on how to set the separator text.

separator_block_width

integer

The amount of pixels to leave blank after the block. The separator text will be displayed centered in this gap. The default is 9 pixels.

markup

string

The type of markup to use when parsing the text for the block. This can either be pango or none (default).

Other properties may be given and swaybar will ignore any property that it does not know. It is recommended to prefix any custom properties with an underscore to make it easier to distinguish them from protocol properties.

### BODY EXAMPLE

```
[
	[
		{
			"full_text": "25%",
			"min_width": "100%",
			"urgent": false
		},
		{
			"full_text": "Thu 30 May 2019 02:15:15"
		}
	],
	[
		{
			"full_text": "20%",
			"min_width": "100%",
			"urgent": false
		},
		{
			"full_text": "Thu 30 May 2019 02:20:52"
		}
	],
	[
		{
			"full_text": "15%",
			"min_width": "100%",
			"urgent": true
		},
		{
			"full_text": "Thu 30 May 2019 02:25:41"
		}
	],
	...
```

### FULL BLOCK EXAMPLE

```
{
	"full_text": "Thu 30 May 2019 02:09:15",
	"short_text": "02:09",
	"color": "#ccccccff",
	"background": "#111111ff",
	"border": "#222222ff",
	"border_top": 1,
	"border_bottom": 1,
	"border_left": 1,
	"border_right": 1,
	"min_width": 100,
	"align": "center",
	"name": "clock",
	"instance": "edt",
	"urgent": false,
	"separator": true,
	"separator_block_width": 5,
	"markup": "none"
}
```

## CLICK EVENTS
If requested in the header, swaybar will write a JSON object, that can be read from standard in, when the user clicks on a block. The event object will have the following properties:

PROPERTY

DATA TYPE

DESCRIPTION

name

string

The name of the block, if set

instance

string

The instance of the block, if set

x

integer

The x location that the click occurred at

y

integer

The y location that the click occurred at

button

integer

The x11 button number for the click. If the button does not have an x11 button mapping, this will be 0.

event

integer

The event code that corresponds to the button for the click

relative_x

integer

The x location of the click relative to the top-left of the block

relative_y

integer

The y location of the click relative to the top-left of the block

width

integer

The width of the block in pixels

height

integer

The height of the block in pixels

Differences from i3bar's protocol:

- button may be 0 for buttons that do not have x11 button mappings

- event has been introduced to allow for non-x11 buttons to be represented

- The modifiers property is not currently added by swaybar

### EXAMPLE

```
{
	"name": "clock",
	"instance": "edt",
	"x": 1900,
	"y": 10,
	"button": 1,
	"event": 274,
	"relative_x": 100,
	"relative_y": 8,
	"width": 120,
	"height": 18
}
```

## SEE ALSO
sway-bar(5)

branch: sisyphus


syncthing-bep

package: syncthing

title: syncthing-bep(7)

summary: Block Exchange Protocol v1

text:
# syncthing-bep(7)

## NAME
syncthing-bep - Block Exchange Protocol v1

## INTRODUCTION AND DEFINITIONS
The Block Exchange Protocol (BEP) is used between two or more devices thus forming a cluster. Each device has one or more folders of files described by the local model, containing metadata and block hashes. The local model is sent to the other devices in the cluster. The union of all files in the local models, with files selected for highest change version, forms the global model. Each device strives to get its folders in sync with the global model by requesting missing or outdated blocks from the other devices in the cluster.

File data is described and transferred in units of blocks, each being from 128 KiB (131072 bytes) to 16 MiB in size, in steps of powers of two. The block size may vary between files but is constant in any given file, except for the last block which may be smaller.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 <https://datatracker.ietf.org/doc/html/rfc2119.html>.

## TRANSPORT AND AUTHENTICATION
BEP is deployed as the highest level in a protocol stack, with the lower level protocols providing encryption and authentication.

```
+-----------------------------+
|   Block Exchange Protocol   |
|-----------------------------|
| Encryption & Auth (TLS 1.3) |
|-----------------------------|
|      Reliable Transport     |
|-----------------------------|
v             ...             v
```

The encryption and authentication layer SHALL use TLS 1.3 or a higher revision.

The exact nature of the authentication is up to the application, however it SHALL be based on the TLS certificate presented at the start of the connection. Possibilities include certificates signed by a common trusted CA, preshared certificates, preshared certificate fingerprints or certificate pinning combined with some out of band first verification. The reference implementation uses preshared certificate fingerprints (SHA-256) referred to as “Device IDs”.

There is no required order or synchronization among BEP messages except as noted per message type - any message type may be sent at any time and the sender need not await a response to one message before sending another.

The underlying transport protocol MUST guarantee reliable packet delivery.

In this document, in diagrams and text, “bit 0” refers to the most significant bit of a word; “bit 15” is thus the least significant bit of a 16 bit word (int16) and “bit 31” is the least significant bit of a 32 bit word (int32). Non protocol buffer integers are always represented in network byte order (i.e., big endian) and are signed unless stated otherwise, but when describing message lengths negative values do not make sense and the most significant bit MUST be zero.

The protocol buffer schemas in this document are in proto3 syntax. This means, among other things, that all fields are optional and will assume their default value when missing. This does not necessarily mean that a message is valid with all fields empty - for example, an index entry for a file that does not have a name is not useful and MAY be rejected by the implementation. However the folder label is for human consumption only so an empty label should be accepted - the implementation will have to choose some way to represent the folder, perhaps by using the ID in it’s place or automatically generating a label.

## PRE-AUTHENTICATION MESSAGES
AFTER establishing a connection, but BEFORE performing any authentication, devices MUST exchange Hello messages.

Hello messages are used to carry additional information about the peer, which might be of interest to the user even if the peer is not permitted to communicate due to failing authentication. Note that the certificate based authentication may be considered part of the TLS handshake that precedes the Hello message exchange, but even in the case that a connection is rejected a Hello message must be sent before the connection is terminated.

Hello messages MUST be prefixed with an int32 containing the magic number 0x2EA7D90B, followed by an int16 representing the size of the message, followed by the contents of the Hello message itself.

```
 0                   1

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Magic             |
|           (32 bits)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               /
\             Hello             \
/                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

The Hello message itself is in protocol buffer format with the following schema:

```
message Hello {

    string device_name    = 1;

    string client_name    = 2;

    string client_version = 3;
}
```

### Fields (Hello message)
The device_name is a human readable (configured or auto detected) device name or host name, for the remote device.

The client_name and client_version identifies the implementation. The values SHOULD be simple strings identifying the implementation name, as a user would expect to see it, and the version string in the same manner. An example client name is “syncthing” and an example client version is “v0.7.2”. The client version field SHOULD follow the patterns laid out in the Semantic Versioning <https://semver.org/> standard.

Immediately after exchanging Hello messages, the connection MUST be dropped if the remote device does not pass authentication.

## POST-AUTHENTICATION MESSAGES
Every message post authentication is made up of several parts:

- A header length word

- A Header

- A message length word

- A Message

```
 0                   1

 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Header Length         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               /
\            Header             \
/                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Message Length        |
|           (32 bits)           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/                               /
\            Message            \
/                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

The header length word is 16 bits. It indicates the length of the following Header message. The Header is in protocol buffer format. The Header describes the type and compression status of the following message.

The message is preceded by the 32 bit message length word and is one of the concrete BEP messages described below, identified by the type field of the Header.

As always, the length words are in network byte order (big endian).

```
message Header {

    MessageType        type        = 1;

    MessageCompression compression = 2;
}
enum MessageType {

    CLUSTER_CONFIG    = 0;

    INDEX             = 1;

    INDEX_UPDATE      = 2;

    REQUEST           = 3;

    RESPONSE          = 4;

    DOWNLOAD_PROGRESS = 5;

    PING              = 6;

    CLOSE             = 7;
}
enum MessageCompression {

    NONE = 0;

    LZ4  = 1;
}
```

When the compression field is NONE, the message is directly in protocol buffer format.

When the compression field is LZ4, the message consists of a 32 bit integer describing the uncompressed message length followed by a single LZ4 block. After decompressing the LZ4 block it should be interpreted as a protocol buffer message just as in the uncompressed case.

## MESSAGE SUBTYPES

### Cluster Config
This informational message provides information about the cluster configuration as it pertains to the current connection. A Cluster Config message MUST be the first post authentication message sent on a BEP connection. Additional Cluster Config messages MAY be sent after the initial exchange to change the connection in place with the update configuration. If an implementation does not support that, it SHOULD close the connection.

### Protocol Buffer Schema

```
message ClusterConfig {

    repeated Folder folders = 1;
}
message Folder {

    string id                    = 1;

    string label                 = 2;

    FolderType type              = 3;

    FolderStopReason stop_reason = 7;

    reserved 4 to 6;

    repeated Device devices = 16;
}
message Device {

    bytes           id                         = 1;

    string          name                       = 2;

    repeated string addresses                  = 3;

    Compression     compression                = 4;

    string          cert_name                  = 5;

    int64           max_sequence               = 6;

    bool            introducer                 = 7;

    uint64          index_id                   = 8;

    bool            skip_introduction_removals = 9;

    bytes           encryption_password_token  = 10;
}
enum Compression {

    METADATA = 0;

    NEVER    = 1;

    ALWAYS   = 2;
}
enum FolderType {

    FOLDER_TYPE_SEND_RECEIVE      = 0;

    FOLDER_TYPE_SEND_ONLY         = 1;

    FOLDER_TYPE_RECEIVE_ONLY      = 2;

    FOLDER_TYPE_RECEIVE_ENCRYPTED = 3;
}
enum FolderStopReason {

    FOLDER_STOP_REASON_RUNNING = 0;

    FOLDER_STOP_REASON_PAUSED  = 1;
}
```

### Fields (Cluster Config Message)
The folders field contains the list of folders that will be synchronized over the current connection.

### Fields (Folder Message)
The id field contains the folder ID, which is the unique identifier of the folder.

The label field contains the folder label, the human readable name of the folder.

The folder_type field contains the type of the folder as defined by the FolderType enumeration.

The stop_reason field is set for folders that are currently stopped for any reason. The zero means that the folder is not stopped; further reasons are defined by the FolderStopReason enumeration.

The devices field is a list of devices participating in sharing this folder.

### Fields (Device Message)
The device id field is a 32 byte number that uniquely identifies the device. For instance, the reference implementation uses the SHA-256 of the device X.509 certificate.

The name field is a human readable name assigned to the described device by the sending device. It MAY be empty and it need not be unique.

The list of addresses is that used by the sending device to connect to the described device.

The compression field indicates the compression mode in use for this device and folder. The following values are valid:

0

Compress metadata. This enables compression of metadata messages such as Index.

1

Compression disabled. No compression is used on any message.

2

Compress always. Metadata messages as well as Response messages are compressed.

The cert_name field indicates the expected certificate name for this device. It is commonly blank, indicating to use the implementation default.

The max_sequence field contains the highest sequence number of the files in the index. See Delta Index Exchange for the usage of this field.

The introducer field is set for devices that are trusted as cluster introducers.

The index_id field contains the unique identifier for the current set of index data. See Delta Index Exchange for the usage of this field.

The skip_introduction_removals field signifies if the remote device has opted to ignore introduction removals for the given device. This setting is copied across as we are being introduced to a new device.

The encryption_password_token field contains a token derived from the password, that is used to encrypt data sent to this device. If the device is the same as the device sending the message, it signifies that the device itself has encrypted data that was encrypted with the given token. It is empty or missing if there is no encryption. See Untrusted Device Encryption for details on the encryption scheme.

### Index and Index Update
The Index and Index Update messages define the contents of the senders folder. An Index message represents the full contents of the folder and thus supersedes any previous index. An Index Update amends an existing index with new information, not affecting any entries not included in the message. An Index Update MAY NOT be sent unless preceded by an Index, unless a non-zero Max Sequence has been announced for the given folder by the peer device.

The Index and Index Update messages are currently identical in format, although this is not guaranteed to be the case in the future.

### Protocol Buffer Schema

```
message Index {

    string            folder = 1;

    repeated FileInfo files  = 2;
}
message IndexUpdate {

    string            folder = 1;

    repeated FileInfo files  = 2;
}
message FileInfo {

    string       name           = 1;

    FileInfoType type           = 2;

    int64        size           = 3;

    uint32       permissions    = 4;

    int64        modified_s     = 5;

    int32        modified_ns    = 11;

    uint64       modified_by    = 12;

    bool         deleted        = 6;

    bool         invalid        = 7;

    bool         no_permissions = 8;

    Vector       version        = 9;

    int64        sequence       = 10;

    int32        block_size     = 13;

    repeated BlockInfo Blocks         = 16;

    string             symlink_target = 17;
}
enum FileInfoType {

    FILE              = 0;

    DIRECTORY         = 1;

    SYMLINK_FILE      = 2 [deprecated = true];

    SYMLINK_DIRECTORY = 3 [deprecated = true];

    SYMLINK           = 4;
}
message BlockInfo {

    int64 offset = 1;

    int32 size   = 2;

    bytes hash   = 3;

    reserved 4;
}
message Vector {

    repeated Counter counters = 1;
}
message Counter {

    uint64 id    = 1;

    uint64 value = 2;
}
```

### Fields (Index Message)
The folder field identifies the folder that the index message pertains to.

The files field is a list of files making up the index information.

### Fields (FileInfo Message)
The name is the file name path relative to the folder root. Like all strings in BEP, the Name is always in UTF-8 NFC regardless of operating system or file system specific conventions. The name field uses the slash character (“/”) as path separator, regardless of the implementation’s operating system conventions. The combination of folder and name uniquely identifies each file in a cluster.

The type field contains the type of the described item. The type is one of file (0), directory (1), or symlink (4).

The size field contains the size of the file, in bytes. For directories and symlinks the size is zero.

The permissions field holds the common Unix permission bits. An implementation MAY ignore or interpret these as is suitable on the host operating system.

The modified_s time is expressed as the number of seconds since the Unix Epoch (1970-01-01 00:00:00 UTC). The modified_ns field holds the nanosecond part of the modification time.

The modified_by field holds the short id of the client that last made any modification to the file whether add, change or delete. This will be overwritten every time a change is made to the file by the last client to do so and so does not hold history.

The deleted field is set when the file has been deleted. The block list SHALL be of length zero and the modification time indicates the time of deletion or, if the time of deletion is not reliably determinable, the last known modification time.

The invalid field is set when the file is invalid and unavailable for synchronization. A peer MAY set this bit to indicate that it can temporarily not serve data for the file.

The no_permissions field is set when there is no permission information for the file. This is the case when it originates on a file system which does not support permissions. Changes to only permission bits SHOULD be disregarded on files with this bit set. The permissions bits MUST be set to the octal value 0666.

The version field is a version vector describing the updates performed to a file by all members in the cluster. Each counter in the version vector is an ID-Value tuple. The ID is the first 64 bits of the device ID. The Value is a simple incrementing counter, starting at zero. The combination of Folder, Name and Version uniquely identifies the contents of a file at a given point in time.

The sequence field is the value of a device local monotonic clock at the time of last local database update to a file. The clock ticks on every local database update, thus forming a sequence number over database updates.

The block_size field is the size, in bytes, of each individual block in the block list (except, possibly, the last block). If this field is missing or zero, the block size is assumed to be 128 KiB (131072 bytes). Valid values of this field are the powers of two from 128 KiB through 16 MiB. See also Selection of Block Size.

The blocks list contains the size and hash for each block in the file. Each block represents a block_size-sized slice of the file, except for the last block which may represent a smaller amount of data. The block list is empty for directories and symlinks.

The symlink_target field contains the symlink target, for entries of symlink type. It is empty for all other entry types.

### Request
The Request message expresses the desire to receive a data block corresponding to a part of a certain file in the peer’s folder.

### Protocol Buffer Schema

```
message Request {

    int32  id             = 1;

    string folder         = 2;

    string name           = 3;

    int64  offset         = 4;

    int32  size           = 5;

    bytes  hash           = 6;

    bool   from_temporary = 7;

    int32 block_no        = 9;

    reserved 8;
}
```

### Fields
The id is the request identifier. It will be matched in the corresponding Response message. Each outstanding request must have a unique ID.

The folder and name fields are as documented for the Index message. The offset and size fields specify the region of the file to be transferred. This SHOULD equate to exactly one block as seen in an Index message.

The hash field MAY be set to the expected hash value of the block. If set, the other device SHOULD ensure that the transmitted block matches the requested hash. The other device MAY reuse a block from a different file and offset having the same size and hash, if one exists.

The from_temporary field is set to indicate that the read should be performed from the temporary file (converting name to it’s temporary form) and falling back to the non temporary file if any error occurs. Knowledge of contents of temporary files comes from DownloadProgress messages.

### Response
The Response message is sent in response to a Request message.

### Protocol Buffer Schema

```
message Response {

    int32     id   = 1;

    bytes     data = 2;

    ErrorCode code = 3;
}
enum ErrorCode {

    NO_ERROR     = 0;

    GENERIC      = 1;

    NO_SUCH_FILE = 2;

    INVALID_FILE = 3;
}
```

### Fields
The id field is the request identifier. It must match the ID of the Request that is being responded to.

The data field contains either the requested data block or is empty if the requested block is not available.

The code field contains an error code describing the reason a Request could not be fulfilled, in the case where zero length data was returned. The following values are defined:

0

No Error (data should be present)

1

Generic Error

2

No Such File (the requested file does not exist, or the offset is outside the acceptable range for the file)

3

Invalid (file exists but has invalid bit set or is otherwise unavailable)

### DownloadProgress
The DownloadProgress message is used to notify remote devices about partial availability of files. By default, these messages are sent every 5 seconds, and only in the cases where progress or state changes have been detected. Each DownloadProgress message is addressed to a specific folder and MUST contain zero or more FileDownloadProgressUpdate messages.

### Protocol Buffer Schema

```
message DownloadProgress {

    string                              folder  = 1;

    repeated FileDownloadProgressUpdate updates = 2;
}
message FileDownloadProgressUpdate {

    FileDownloadProgressUpdateType update_type   = 1;

    string                         name          = 2;

    Vector                         version       = 3;

    repeated int32                 block_indexes = 4;
}
enum FileDownloadProgressUpdateType {

    APPEND = 0;

    FORGET = 1;
}
```

### Fields (DownloadProgress Message)
The folder field represents the ID of the folder for which the update is being provided.

The updates field is a list of progress update messages.

### Fields (FileDownloadProgressUpdate Message)
The update_type indicates whether the update is of type append (0) (new blocks are available) or forget (1) (the file transfer has completed or failed).

The name field defines the file name from the global index for which this update is being sent.

The version message defines the version of the file for which this update is being sent.

The block_indexes field is a list of positive integers, where each integer represents the index of the block in the FileInfo message Blocks array that has become available for download.

For example an integer with value 3 represents that the data defined in the fourth BlockInfo message of the FileInfo message of that file is now available. Please note that matching should be done on name AND version. Furthermore, each update received is incremental, for example the initial update message might contain indexes 0, 1, 2, an update 5 seconds later might contain indexes 3, 4, 5 which should be appended to the original list, which implies that blocks 0-5 are currently available.

Block indexes MAY be added in any order. An implementation MUST NOT assume that block indexes are added in any specific order.

The forget field being set implies that previously advertised file is no longer available, therefore the list of block indexes should be truncated.

Messages with the forget field set MUST NOT have any block indexes.

Any update message which is being sent for a different version of the same file name must be preceded with an update message for the old version of that file with the forget field set.

As a safeguard on the receiving side, the value of version changing between update messages implies that the file has changed and that any indexes previously advertised are no longer available. The list of available block indexes MUST be replaced (rather than appended) with the indexes specified in this message.

### Ping
The Ping message is used to determine that a connection is alive, and to keep connections alive through state tracking network elements such as firewalls and NAT gateways. A Ping message is sent every 90 seconds, if no other message has been sent in the preceding 90 seconds.

### Protocol Buffer Schema

```
message Ping {
}
```

### Close
The Close message MAY be sent to indicate that the connection will be torn down due to an error condition. A Close message MUST NOT be followed by further messages.

### Protocol Buffer Schema

```
message Close {

    string reason = 1;
}
```

### Fields
The reason field contains a human readable description of the error condition.

## SHARING MODES

### Trusted
Trusted mode is the default sharing mode. Updates are exchanged in both directions.

```
+------------+     Updates      /---------\
|            |  ----------->   /           \
|   Device   |                 |  Cluster  |
|            |  <-----------   \           /
+------------+     Updates      \---------/
```

### Send Only
In send only mode, a device does not apply any updates from the cluster, but publishes changes of its local folder to the cluster as usual.

```
+------------+     Updates      /---------\
|            |  ----------->   /           \
|   Device   |                 |  Cluster  |
|            |                 \           /
+------------+                  \---------/
```

### Receive Only
In receive only mode, a device does not send any updates to the cluster, but accepts changes to its local folder from the cluster as usual.

```
+------------+     Updates      /---------\
|            |  <-----------   /           \
|   Device   |                 |  Cluster  |
|            |                 \           /
+------------+                  \---------/
```

## DELTA INDEX EXCHANGE
Index data must be exchanged whenever two devices connect so that one knows the files available on the other. In the most basic case this happens by way of sending an Index message followed by one or more Index Update messages. Any previous index data known for a remote device is removed and replaced with the new index data received in an Index message, while the contents of an Index Update message is simply added to the existing index data.

For situations with large indexes or frequent reconnects this can be quite inefficient. A mechanism can then be used to retain index data between connections and only transmit any changes since that data on connection start. This is called “delta indexes”. To enable this mechanism the sequence and index ID fields are used.

Sequence:

Each index item (i.e., file, directory or symlink) has a sequence number field. It contains the value of a counter at the time the index item was updated. The counter increments by one for each change. That is, as files are scanned and added to the index they get assigned sequence numbers 1, 2, 3 and so on. The next file to be changed or detected gets sequence number 4, and future updates continue in the same fashion.

Index ID:

Each folder has an Index ID. This is a 64 bit random identifier set at index creation time.

Given the above, we know that the tuple {index ID, maximum sequence number} uniquely identifies a point in time of a given index. Any further changes will increase the sequence number of some item, and thus the maximum sequence number for the index itself. Should the index be reset or removed (i.e., the sequence number reset to zero), a new index ID must be generated.

By letting a device know the {index ID, maximum sequence number} we have for their index data, that device can arrange to only transmit Index Update messages for items with a higher sequence number. This is the delta index mechanism.

The index ID and maximum sequence number known for each device is transmitted in the Cluster Config message at connection start.

For this mechanism to be reliable it is essential that outgoing index information is ordered by increasing sequence number. Devices announcing a non-zero index ID in the Cluster Config message MUST send all index data ordered by increasing sequence number. Devices not intending to participate in delta index exchange MUST send a zero index ID or, equivalently, not send the index_id attribute at all.

## MESSAGE LIMITS
An implementation MAY impose reasonable limits on the length of messages and message fields to aid robustness in the face of corruption or broken implementations. An implementation should strive to keep messages short and to the point, favouring more and smaller messages over fewer and larger. For example, favour a smaller Index message followed by one or more Index Update messages rather than sending a very large Index message.

The Syncthing implementation imposes a hard limit of 500,000,000 bytes on all messages. Attempting to send or receive a larger message will result in a connection close. This size was chosen to accommodate Index messages containing a large block list. It’s intended that the limit may be further reduced in a future protocol update supporting variable block sizes (and thus shorter block lists for large files).

## SELECTION OF BLOCK SIZE
The desired block size for any given file is the smallest block size that results in fewer than 2000 blocks, or the maximum block size for larger files. This rule results in the following table of block sizes per file size:

File Size

Block Size

0 - 250 MiB

128 KiB

250 MiB - 500 MiB

256 KiB

500 MiB - 1 GiB

512 KiB

1 GiB - 2 GiB

1 MiB

2 GiB - 4 GiB

2 MiB

4 GiB - 8 GiB

4 MiB

8 GiB - 16 GiB

8 MiB

16 GiB - up

16 MiB

An implementation MAY deviate from the block size rule when there is good reason to do so. For example, if a file has been indexed at a certain block size and grows beyond 2000 blocks it may be retained at the current block size for practical reasons. When there is no overriding reason to the contrary, such as when indexing a new file for the first time, the block size rule above SHOULD be followed.

An implementation MUST therefore accept files with a block size differing from the above rule. This does not mean that arbitrary block sizes are allowed. The block size used MUST be exactly one of the power-of-two block sizes listed in the table above.

## EXAMPLE EXCHANGE
\#

A

B

1

ClusterConfiguration->

<-ClusterConfiguration

2

Index->

<-Index

3

IndexUpdate->

<-IndexUpdate

4

IndexUpdate->

5

Request->

6

Request->

7

Request->

8

Request->

9

<-Response

10

<-Response

11

<-Response

12

<-Response

13

Index Update->

…

14

<-Ping

15

Ping->

The connection is established and at 1. both peers send ClusterConfiguration messages and then Index records. The Index records are received and both peers recompute their knowledge of the data in the cluster. In this example, peer A has four missing or outdated blocks. At 5 through 8 peer A sends requests for these blocks. The requests are received by peer B, who retrieves the data from the folder and transmits Response records (9 through 12). Device A updates their folder contents and transmits an Index Update message (13). Both peers enter idle state after 13. At some later time 14, the ping timer on device B expires and a Ping message is sent. The same process occurs for device A at 15.

## AUTHOR
The Syncthing Authors

## COPYRIGHT
2014-2026, The Syncthing Authors


syncthing-device-ids

title: syncthing-device-ids(7)

summary: Understanding Device IDs

text:
# syncthing-device-ids(7)

## NAME
syncthing-device-ids - Understanding Device IDs

Every device is identified by a device ID. The device ID is used for address resolution, authentication and authorization. The term “device ID” could interchangeably have been “key ID” since the device ID is a direct property of the public key in use.

## KEYS
To understand device IDs we need to look at the underlying mechanisms. At first startup, Syncthing will create a public/private keypair.

Currently this is a 384 bit ECDSA key (3072 bit RSA prior to v0.12.5, which is what is used as an example in this article). The keys are saved in the form of the private key (key.pem) and a self signed certificate (cert.pem). The self signing part doesn’t actually add any security or functionality as far as Syncthing is concerned but it enables the use of the keys in a standard TLS exchange.

The typical certificate will look something like this, inspected with openssl x509:

```
Certificate:

    Data:

        Version: 3 (0x2)

        Serial Number: 0 (0x0)

        Signature Algorithm: sha1WithRSAEncryption

        Issuer: CN=syncthing

        Validity

            Not Before: Mar 30 21:10:52 2014 GMT

            Not After : Dec 31 23:59:59 2049 GMT

        Subject: CN=syncthing

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

            RSA Public Key: (3072 bit)

                Modulus (3072 bit):

                    00:da:83:8a:c0:95:af:0a:42:af:43:74:65:29:f2:

                    30:e3:b9:12:d2:6b:70:93:da:0b:7b:8a:1e:e5:79:

                    ...

                    99:09:4c:a9:7b:ba:4a:6a:8b:3b:e6:e7:c7:2c:00:

                    90:aa:bc:ad:94:e7:80:95:d2:1b

                Exponent: 65537 (0x10001)

        X509v3 extensions:

            X509v3 Key Usage: critical

                Digital Signature, Key Encipherment

            X509v3 Extended Key Usage:

                TLS Web Server Authentication, TLS Web Client Authentication

            X509v3 Basic Constraints: critical

                CA:FALSE

    Signature Algorithm: sha1WithRSAEncryption

        68:72:43:8b:83:61:09:68:f0:ef:f0:43:b7:30:a6:73:1e:a8:

        d9:24:6c:2d:b4:bc:c9:e8:3e:0b:1e:3c:cc:7a:b2:c8:f1:1d:

        ...

        88:7e:e2:61:aa:4c:02:e3:64:b0:da:70:3a:cd:1c:3d:86:db:

        df:54:b9:4e:be:1b
```

We can see here that the certificate is little more than a container for the public key; the serial number is zero and the Issuer and Subject are both “syncthing” where a qualified name might otherwise be expected.

An advanced user could replace the key.pem and cert.pem files with a keypair generated directly by the openssl utility or other mechanism.

## DEVICE IDS
To form a device ID the SHA-256 hash of the certificate data in DER form is calculated. This means the hash covers all information under the Certificate: section above.

The hashing results in a 256 bit hash which we encode using base32. Base32 encodes five bits per character so we need 256 / 5 = 51.2 characters to encode the device ID. This becomes 52 characters in practice, but 52 characters of base32 would decode to 260 bits which is not a whole number of bytes. The base32 encoding adds padding to 280 bits (the next multiple of both 5 and 8 bits) so the resulting ID looks something like:

```
MFZWI3DBONSGYYLTMRWGC43ENRQXGZDMMFZWI3DBONSGYYLTMRWA====
```

The padding (====) is stripped away, the device ID split into four groups, and check digits <https://forum.syncthing.net/t/v0-9-0-new-node-id-format/478> are added for each group. For presentation purposes the device ID is grouped with dashes, resulting in the final value:

```
MFZWI3D-BONSGYC-YLTMRWG-C43ENR5-QXGZDMM-FZWI3DP-BONSGYY-LTMRWAD
```

### Connection Establishment
Now we know what device IDs are, here’s how they are used in Syncthing. When you add a device ID to the configuration, Syncthing will attempt to connect to that device. The first thing we need to do is figure out the IP and port to connect to. There are three possibilities here:

- The IP and port can be set statically in the configuration. The IP can equally well be a host name, so if you have a static IP or a dynamic DNS setup this might be a good option.

- Using local discovery, if enabled. Every Syncthing instance on a LAN periodically broadcasts information about itself (device ID, address, port number). If we’ve seen one of these broadcasts for a given device ID that’s where we try to connect.

- Using global discovery, if enabled. Every Syncthing instance announces itself to the global discovery service (device ID and external port number - the internal address is not announced to the global server). If we don’t have a static address and haven’t seen any local announcements the global discovery server will be queried for an address.

Once we have an address and port a TCP connection is established and a TLS handshake performed. As part of the handshake both devices present their certificates. Once the handshake has completed and the peer certificate is known, the following steps are performed:

1.

Calculate the remote device ID by processing the received certificate as above.

2.

Weed out a few possible misconfigurations - i.e. if the device ID is that of the local device or of a device we already have an active connection to. Drop the connection in these cases.

3.

Verify the remote device ID against the configuration. If it is not a device ID we are expecting to talk to, drop the connection.

4.

Verify the certificate CommonName against the configuration. By default, we expect it to be syncthing, but when using custom certificates this can be changed.

5.

If everything checks out so far, accept the connection.

## AN ASIDE ABOUT COLLISIONS
The SHA-256 hash is cryptographically collision resistant. This means that there is no way that we know of to create two different messages with the same hash.

You can argue that of course there are collisions - there’s an infinite amount of inputs and a finite amount of outputs - so by definition there are infinitely many messages that result in the same hash.

I’m going to quote stack overflow <https://stackoverflow.com/questions/4014090/is-it-safe-to-ignore-the-possibility-of-sha-collisions-in-practice> here:

The usual answer goes thus: what is the probability that a rogue asteroid crashes on Earth within the next second, obliterating civilization-as-we- know-it, and killing off a few billion people ? It can be argued that any unlucky event with a probability lower than that is not actually very important. If we have a “perfect” hash function with output size n, and we have p messages to hash (individual message length is not important), then probability of collision is about p2/2n+1 (this is an approximation which is valid for “small” p, i.e. substantially smaller than 2n/2). For instance, with SHA-256 (n=256) and one billion messages (p=10^9) then the probability is about 4.3*10^-60.

A mass-murderer space rock happens about once every 30 million years on average. This leads to a probability of such an event occurring in the next second to about 10^-15. That’s 45 orders of magnitude more probable than the SHA-256 collision. Briefly stated, if you find SHA-256 collisions scary then your priorities are wrong.

It’s also worth noting that the property of SHA-256 that we are using is not simply collision resistance but resistance to a preimage attack, i.e. even if you can find two messages that result in a hash collision that doesn’t help you attack Syncthing (or TLS in general). You need to create a message that hashes to exactly the hash that my certificate already has or you won’t get in.

Note also that it’s not good enough to find a random blob of bits that happen to have the same hash as my certificate. You need to create a valid DER-encoded, signed certificate that has the same hash as mine. The difficulty of this is staggeringly far beyond the already staggering difficulty of finding a SHA-256 collision.

## PROBLEMS AND VULNERABILITIES
As far as I know, these are the issues or potential issues with the above mechanism.

### Discovery Spoofing
Currently, the local discovery mechanism isn’t protected by crypto. This means that any device can in theory announce itself for any device ID and potentially receive connections for that device from the local network.

### Long Device IDs are Painful
It’s a mouthful to read over the phone, annoying to type into an SMS or even into a computer. And it needs to be done twice, once for each side.

This isn’t a vulnerability as such, but a user experience problem. There are various possible solutions:

- Use shorter device IDs with verification based on the full ID (“You entered MFZWI3; I found and connected to a device with the ID MFZWI3-DBONSG-YYLTMR-WGC43E-NRQXGZ-DMMFZW-I3DBON-SGYYLT-MRWA, please confirm that this is correct”).

- Use shorter device IDs with an out of band authentication, a la Bluetooth pairing. You enter a one time PIN into Syncthing and give that PIN plus a short device ID to another user. On initial connect, both sides verify that the other knows the correct PIN before accepting the connection.

## AUTHOR
The Syncthing Authors

## COPYRIGHT
2014-2026, The Syncthing Authors