First contact - What are listener?

I am starting to use Syncthing and trying to understand the underlying concepts…so bare with me…I understand, it is all about the devices which I set up and connect, so what the hack are “listeners”, then? Is there any (!) “third party” involved when i connect two devices, e.g. for some reasons connected to the underlying protocol? Thx for any hint to deepen my understanding here…Martin

1 Like

If you are interested in the internals and more advanced configuration, then I would suggest reading the Docs from cover to cover, as almost everything is explained there in details. The forum also has a lot of information if you search for it :slightly_smiling_face:.

1 Like

“Listener” is terminology for an open network port where Syncthing accepts incoming connections from other devices. It does not imply some third party “listening” to your traffic.

I can totally understand the confusion, as I wondered about the term myself some time ago. It’s a rather technical term and the icon next to it doesn’t help. We should add an explanation right there in the GUI and use a different wording if a consensus can be reached. That would break translations, but frankly at least the German word was even more confusing to me.

Or move this piece of information somewhere else where the average user only looks at it when asked to diagnose a connection problem. Showing which listeners are active would be a great addition then.

1 Like

Yeah, a one-sentence explanation what “listeners” mean, plus the same for the four options, i.e.

would indeed be nice. Alternatively, a direct link to the Docs with the relevant content could also probably do it.

The user would still at least have to open the Settings modal to see them. There is no real place in the main GUI screen for additional info for specific items though, unless you add mouse-hover tooltips, which are not great as being difficult to access on touch screen devices.

Doesn’t the overlay for failed discovery open onclick?

Thx, this is answering my question … and I would support the idea to have this included more elaborated in the manuals…it is ! confusing… M.

“Failed” is the keyword here :wink:.

Also, I think that the problem is that the user has no idea what the item itself means, regardless whether it has been successful or not.

My point is that we already have a mobile friendly UI component to display listerners, discovery etc. We should probably enable it by default and not only to list errors.

I’m also for better terms in the UI.

The listeners are actually not clickable (just checked in the code). There is a special popup for “discovery failures”, but nothing else than that. A new popup with listeners’ information with actual addresses and such would likely have to be implemented separately.

Just my meta-2-cents, ignore at will:
This seems like the kind of issue, that’s pretty simple at its core and if you can/will do it yourself, fixing it takes less time than discussing it. And if you can’t do it yourself, discussing it is pointless unless you find someone to do it.

Agree, and I might take a stab at fixing it if time permits. If someone else wants to try, just go ahead.

1 Like

I wonder whether we should display more elaborate information about discovery and listeners in a modal overlay in general. Not only in case of errors, but also the working ones, along with a very short explanation what “listener” and “discovery” even means.

I could extend and rename discoveryFailuresModalView.html to show working ones as well, then copy it to a listenersModalView.html. Or even share the same basic structure, similar to what was done for the revertOverrideView.html.

What do you think? Get rid of the tooltips or is this heading to modal dialog proliferation?

EDIT: gui: Modal dialog for listeners and discovery status. by acolomb · Pull Request #7539 · syncthing/syncthing · GitHub opened with a draft of the common status dialog.

Some ideas for new, less technical terminology:

Listeners 3/3 →

  • Accepting Connections via 3/3
  • Awaiting Connections on 3/3

Discovery 5/5 →

  • Finding Devices via 5/5
  • Discovery Mechanisms 5/5
  • Discovery Methods 5/5

@Martin1 which of those would you have found least confusing / easiest to understand? (Assuming each of the counts is clickable for more details)

I think that it would be nice to have both working ones and failures included in the modal. Having a short explanation would be useful, but there is also the question of whether the same explanation should be put in the Settings under each of the respective options. Although, when it comes to the Settings, I believe that having a help link to the Docs would probably be more appropriate, but I’m not sure if all of them are even explained in the Docs (as separate entries, at least).

When it comes to renaming “listeners” and “discovery” to more friendly names - it would probably be good to make them less confusing for new users, but one problem here is that these terms are used in many different places right now, both in the GUI, and also in the Docs. If you rename them just in the main part of the GUI and leave the rest unchanged, then the context will be lost.

Actually within the GUI it is pretty well contained, if you search for “listener” or “discovery” within all HTML files. I will go through the docs when the PR is ready to merge and update there.

Having these terms in just one spot on the GUI really doesn’t help understanding what they do, so I think we can’t make it much worse. Having seen them first in a translated version (German Zuhörer), I couldn’t even make the connection what English term I should look for in the docs to understand them… I’d keep the old (technical) terms in the dialog heading, so it’s only the first glance overview where the technical context is lost.

Any opinions on the label renaming suggestions?

How about simply something like

  • Listening Connections
  • Discovery Servers

The original terminology is kept, but with the “connections” and “servers” it makes the two more obvious, and especially in the former, the whole term “listening connections” would be much less scary than just “listeners”, as it is the case right now. Obviously, the user will still have to read up on each of them, either in the pop-up modal or in the Docs, if they want to understand the exact meaning, but still…

I don’t think “listening” makes any sense to a non-technical user. It’s mostly based on the Berkeley socket API’s listen() function. But anyone not familiar with the term might think this is some kind of smart speaker or digital assistant thing? IIRC it also includes relay connections btw.

Regarding discovery, those are not just servers, but also e.g. local LAN announcements.

It may not be the best, but at least you can search for the term and get some meaningful information. If you search for “listeners”, the first result on Google is a Japanese anime :sweat_smile:.

I’m not sure about discovery then, but as long as the term “discovery” itself is included, I doubt that the meaning will be any clearer for an average user anyway.