SYNCTHING-GLOBALDISCO(7)           Syncthing          SYNCTHING-GLOBALDISCO(7)



NNAAMMEE
       syncthing-globaldisco - Global Discovery Protocol v3

AANNNNOOUUNNCCEEMMEENNTTSS
       A  device  should  announce itself at startup. It does this by an HTTPS
       POST to the announce server URL. Standard discovery currently  requires
       the  path to be â/v2/â, yet this can be up to the discovery server. The
       POST has a JSON payload listing connection addresses (if any):

          {
                  addresses: ["tcp://192.0.2.45:22000", "tcp://:22202", "relay://192.0.2.99:22028"],
          }

       Itâs OK for the âaddressesâ field to be either  the  empty  list  ([[]]),
       nnuullll,  or  missing  entirely. An announcement with the field missing or
       empty is however not usefulâ¦

       Any  empty  or  unspecified   IP   addresses   (i.e.   addresses   like
       ttccpp::////::2222000000, ttccpp::////00..00..00..00::2222000000, ttccpp::////[[::::]]::2222000000) are interpreted as
       referring to the source IP address of the announcement.

       The device ID of the announcing device is not part of the announcement.
       Instead,  the  server  requires  that  the  client  perform certificate
       authentication. The device ID is deduced from  the  presented  certifi‐
       cate.

       The server response is empty, with code 220044 (No Content) on success. If
       no certificate was presented, status 440033 (Forbidden)  is  returned.  If
       the  posted  data  doesnât  conform  to  the  expected format, 440000 (Bad
       Request) is returned.

       In successful responses,  the  server  may  return  a  RReeaannnnoouunnccee--AAfftteerr
       header  containing  the number of seconds after which the client should
       perform a new announcement.

       In error responses, the server may return a RReettrryy--AAfftteerr header contain‐
       ing the number of seconds after which the client should retry.

       Performing announcements significantly more often than indicated by the
       RReeaannnnoouunnccee--AAfftteerr or RReettrryy--AAfftteerr headers may result in the client  being
       throttled.  In  such  cases the server may respond with status code 442299
       (Too Many Requests).

QQUUEERRIIEESS
       Queries are performed as HTTPS GET requests to the announce server URL.
       The  requested  device ID is passed as the query parameter âdeviceâ, in
       canonical      string      form,      i.e.      hhttttppss::////ddiissccoovveerryy..ssyynncc‐‐
       tthhiinngg..nneett//??ddeevviiccee==AABBCC1122334455--........

       Successful  responses  will  have status code 220000 (OK) and carry a JSON
       payload of the same format as the announcement above. The response will
       not contain empty or unspecified addresses.

       If  the  âdeviceâ  query  parameter is missing or malformed, the status
       code 400 (Bad Request) is returned.

       If the device ID is of a valid format but not found  in  the  registry,
       404 (Not Found) is returned.

       If  the  client  has exceeded a rate limit, the server may respond with
       429 (Too Many Requests).

AAUUTTHHEENNTTIICCAATTIIOONN
       Global discovery is spoken over HTTPS and is protected against  attack‐
       ers in the same manner as other HTTPS traffic. However, there are a few
       Syncthing specific considerations on top of this. As  mentioned  above,
       for announcements the client must provide a certificate to prove owner‐
       ship of the announced device ID.

       In addition, Syncthing has a mechanism to verify the  identity  of  the
       discovery server.  While this would normally be accomplished by using a
       CA signed certificate, Syncthing often runs in environments  with  out‐
       dated  or  simply  nonexistent  root CA bundles. Instead, Syncthing can
       verify the discovery server certificate fingerprint using the device ID
       mechanism.  This  is  certificate pinning and conveyed in the Syncthing
       configuration as a synthetic âidâ parameter  on  the  discovery  server
       URL:  hhttttppss::////ddiissccoovveerryy..ssyynncctthhiinngg..nneett//??iidd==.......  The  âidâ  parameter is
       not, in fact, sent to the discovery server -  itâs  used  by  Syncthing
       itself to know which certificate to expect on the server side.

       The public discovery network uses this authentication mechanism instead
       of CA signed certificates.

       The discovery server prints  its  certificate  ID  in  this  manner  on
       startup.

AAUUTTHHOORR
       The Syncthing Authors

CCOOPPYYRRIIGGHHTT
       2014-2019, The Syncthing Authors



v1.19.2                          Apr 05, 2022         SYNCTHING-GLOBALDISCO(7)
