Editing Introduction to a Self Managed Life: a 13 hour & 28 minute presentation by FUTO software (section)

=== Step 4: Configuring Syncthing Discovery Settings ===

<span id="understanding-discovery-methods-why-we-dont-use-them."></span>
==== 4.1 Understanding Discovery Methods &amp; why we DON’T USE THEM. ====

Discovery methods are how the syncthing app on your phone will “find” the server you set up as your backup server.

<blockquote>'''NOTE:''' Our server has a static IP: <code>192.168.5.5</code>. We went through the trouble to make sure it always lives at <code>192.168.5.5</code> via static mappings in '''pfSense''' and configuring a static IP in the server’s networking settings. Our server will '''always''' be present at <code>192.168.5.5</code> or <code>androidstuff.home.arpa</code> while we are connected via VPN. All Syncthing “discovery” is doing is trying to find our machine, but why use a find feature when we already know where it is? This adds another point of failure for no good reason! Think of it like making your iPhone invisible &amp; then enabling '''“find my iPhone.”'''
</blockquote>
This setup we are installing syncthing onto has the following:

# A static IP configured, so that it is '''always''' <code>192.168.5.5</code>
# A static IP mapping configured in our router, so that no other device on our network can ever steal <code>192.168.5.5</code> from the computer running syncthing.
# A static hostname of <code>androidstuff</code> that does not change.
# Dynamic DNS for our main internet connection, so when we are outside our network our '''pfSense''' router &amp; <code>FreeDNS</code> will make sure that <code>louishomeserver.chickenkiller.com</code> always points to our home network IP address.

'''I will showcase local discovery failing on video.''' It ''“works”'' when I initially connect to my server via QR code &amp; visiting it in the browser, but fails when I try to connect again. This is because my VPN is on network <code>192.168.6.0/24</code> and my Syncthing is on <code>192.168.5.0/24</code>. I was hoping local discovery would be “smart” enough to remember the last IP address my server was on since it had not changed, but it did not.

'''NEVER RELY ON SOMETHING ELSE TO BE “SMART” IN SOLVING A PROBLEM THAT DOES NOT HAVE TO EXIST IN THE FIRST PLACE!'''

<span id="local-discovery-do-not-trust"></span>

==== 4.2 Local Discovery – DO NOT TRUST! ====

Local discovery allows Syncthing to find other devices on your local network automatically. Key word, ''local'' – meaning your subnet of <code>192.168.5.0/24</code>. What if you connect via your VPN, which is on <code>192.168.6.0/24</code>?

When we first add the QR code of our Syncthing instance to our Android phone Syncthing app, Syncthing will connect to our desktop server running Syncthing. HOWEVER: our Android application will NOT find the Syncthing server the NEXT time we connect. THIS IS BAD!!

This is even worse than it not working at all, as it will give the false impression that it works. This is how people who have set up “backup solutions” end up as customers of Rossmann Repair Group paying $2000 to recover a hard drive that fell off a balcony.

<span id="connecting-reliably-to-syncthing-without-discovery-hassles"></span>
===== Connecting Reliably to Syncthing without Discovery Hassles =====

This situation is actually '''worse''' than if Syncthing had no Local Discovery feature at all. If it didn’t work from the start, you’d know you couldn’t rely on it and would just hardcode the IP of your Syncthing server right into your Android app, using the server’s local IP to connect directly.

What’s dangerous is that Syncthing’s Android app connects the first time by scanning the QR code on the server, making it seem like it’s actually discovering your computer. But it’s not. Next time you try to connect—especially if you’re on a different subnet via VPN—it’ll fail to find the server.

'''Syncthing doesn’t even remember the last IP address it used, so it ends up trying to rediscover it, failing again.'''

I get it. If it can’t find the server on a different subnet when you’re using a VPN, fine, but it’s dangerous that Syncthing doesn’t try the last known IP to see if it still works.

'''TL;DR – to avoid becoming a data recovery customer, don’t trust local or global discovery. Just use the IP address of the server, which in our case is <code>192.168.5.5</code>, and check that it works three separate times under three separate conditions before ever assuming that it is working, as you should with ANY backup solution!'''

<span id="global-discovery"></span>
==== 4.3 Global Discovery ====

Global discovery helps Syncthing find your devices over the internet. It works by periodically announcing your device’s presence to global discovery servers.

* '''Privacy Implications:''' Higher risk, as it involves sharing your device’s information with external servers. This could potentially expose:
** Your IP address
** The fact that you’re using Syncthing
** When your device is online

The bigger issue with this is not privacy, ''it’s that it is unnecessary'' and adds another point of failure over entering the hostname manually.

<span id="configuring-discovery-settings"></span>
==== 4.2 Configuring Discovery Settings ====

# '''Access Syncthing Settings'''
## Open the Syncthing web interface (typically <code>https://192.168.5.5</code> or <code>https://androidstuff.home.arpa:8384</code>).
## Click on the “Actions” button (gear icon) in the top right corner.
## Select “Settings” from the dropdown menu.
# '''Adjust Discovery Settings'''
## In the Settings page, scroll to the “Connections” section.
## Find the following options:
##* '''Enable Local Discovery:''' Keep this checked.
##* '''Enable Global Discovery:''' Uncheck this box.
## Click “Save” at the bottom of the page.
## Syncthing will prompt you to confirm the changes. Click “Yes” to apply the new settings.

<span id="step-5-connecting-server-syncthing-to-android-syncthing"></span>