2 Likes
1337 nodes divided by (let’s say) 5 nodes per cluster = 267 clusters. Some thoughts:
(1) We don’t know what % of users opt out of the metadata sharing option. If it’s 50%, that implies there are approx 500 clusters out there. Is there some other way to estimate this?
(2) Considering that Syncthing is more secure (and arguably better) than the leading closed-source alternatives, these numbers are tiny. The upside is incredible. The more users, the more quality ideas to move the project forward, and the more skilled people to participate in that.
(3) Worthwhile to consider why the adoption rate is so low. Is it the absence of marketing (expected in an open source project) … or are there real or perceived obstacles to wider adoption?
(4) And finally, I would like to meet the person who orchestrated a cluster of 39 nodes. Wow!
Hmmm…I’m trying to contribute, but two of my Dockerized nodes have this in their logs:
[KVZJP] 18:08:33 INFO: Usage report: Post https://data.syncthing.net/newdata: x509: failed to load system roots and no roots provided
Could this be related to running inside a Docker container or something else? Otherwise they work fine (except local discovery doesn’t work…I have to use IP addresses if global discovery is disabled).
Scott
I’d guess “both”. Less well known, less user friendly.
Syncthing can’t find the certificate roots that should be bundled with the system. It looks in these places: - The Go Programming Language (line 12 etc).
Probably the node list on the global discovery server is a bit closer, since I guess most people let it enabled.
Ah, so I probably need to make sure the ca-certificates are installed for whatever distro is inside the container. I’ll check that when I’m at my computer next. Thanks!
The number of nodes seen on data.syncthing.net is about two thirds of that seen on announce.syncthing.net, and has been pretty much since data.syncthing.net was a thing. I would assume that probably 95% of everyone runs with global discovery enabled (but my guess is worth just as little as anyone elses here), and it seems about 2/3 of those also enable usage reporting. I don’t know which nodes are in the registry on the announce server or if/how they correlate to the public stats, but it would seem likely that one is a subset of the other.
I think everyone missed the 1337 
1 Like
OK - even with wild-assed guesses, we have an “alpha” model to estimate the user base at present. Hey, we have to start somewhere …
Assumption 1:
1337 reported nodes = 2/3 of unique nodes logged at announce.syncthing.net
Assumption 2:
announce.syncthing.net = 95% of nodes (In other words, 5% of users disable global discovery, perhaps they run their own discoserv.)
This means the estimated # of nodes = ((1337 * 3/2) / .95) or 2111 nodes.
I am willing to track this over time. I welcome any ideas to develop more accurate methods to verify our assumptions. This is hopefully a benchmark to measure progress in achieving the big picture objective of generating a much larger community of users.
EDIT: @calmh
Is the announce server database timestamped and easily parsable? I would suggest that we try to exclude nodes that have been abandoned. Instead, we might want to maintain a rolling number of nodes that have connected in the past 30 days - or something like that.
I got the reference. Funny no one else commented on it!
The server logs stats like this:
...
1411282200 Queries:8673 Answered:524 Announces:387 Unknown:31 Limited:0
1411282500 Queries:8691 Answered:527 Announces:385 Unknown:36 Limited:17
1411282800 Queries:8663 Answered:512 Announces:385 Unknown:28 Limited:105
1411282800 Kept:2031 Deleted:132 Took:0.0106s
...
That is, number of queries, announces etc per five minute interval, and the number of entries purged and kept in the database per hour. The “Kept” number is what I referred to, and this is the number of currently active nodes. There’s currently no way (using the announce server) to track nodes active the last 30 days etc since expired announces are purged from the database.
I consider this more of an operational log, for the purposes of operating the announce server, rather than a real source of public statistics. That’s not necessarily what people “sign up” for, although it’s kind of self evident that if you tell an external entity about your existence, that entity knows you exist.
Edit: The numbers above are from the v0.9 announce server. There’s also a v0.8 one with a few hundred nodes on it, steadily decreasing (although not fast enough – upgrade, people!).
No no, I noticed 
Of course not! I mean, I create even my nickname from this number
But I thought it more interesting to speak about the total number of users and nodes.
I should also mention that the Android version currently does not show the “usage reporting” dialog, unless you open the web interface.
So that might skew the numbers a little, and is something to improve.
You can also cheat and use the (public) download statistics per release;
jb@zirc:~ $ curl -s https://api.github.com/repos/syncthing/syncthing/releases\?per_page=1 | egrep 'name|download_count'
"upload_url": "https://uploads.github.com/repos/syncthing/syncthing/releases/566268/assets{?name}",
"tag_name": "v0.9.17",
"name": "v0.9.17",
"name": "md5sum.txt.asc",
"download_count": 15,
"name": "sha1sum.txt.asc",
"download_count": 12,
"name": "syncthing-freebsd-386-v0.9.17.tar.gz",
"download_count": 7,
"name": "syncthing-freebsd-amd64-v0.9.17.tar.gz",
"download_count": 80,
"name": "syncthing-linux-386-v0.9.17.tar.gz",
"download_count": 215,
"name": "syncthing-linux-amd64-v0.9.17.tar.gz",
"download_count": 935,
"name": "syncthing-linux-armv5-v0.9.17.tar.gz",
"download_count": 53,
"name": "syncthing-linux-armv6-v0.9.17.tar.gz",
"download_count": 80,
"name": "syncthing-linux-armv7-v0.9.17.tar.gz",
"download_count": 53,
"name": "syncthing-macosx-amd64-v0.9.17.tar.gz",
"download_count": 204,
"name": "syncthing-windows-386-v0.9.17.zip",
"download_count": 237,
"name": "syncthing-windows-amd64-v0.9.17.zip",
"download_count": 684,
That’s about 2500 downloads for v0.9.17, so roughly that many nodes ought to have been running it at some point. This, again, doesn’t include Android.
For the curious, here’s a summary of downloads per release; https://nym.se/t/release-downloads.txt
Nice spike at 0.8.5. Note that some releases were only “latest” for a few hours, due to various bugs.
The “Kept” number in the server logs is the number of unique nodes that connected in the past 5 minutes?
That’s good hard data. However, I think it excludes a large % of those nodes which are not online 24x7. And I would guess that many mobile nodes (laptops, tablets, phones) are not connected to their Syncthing cluster most of the time.
Hmm … More thinking required here.
That sent an announce packet to the global discovery server in the last hour. (It’s sent every 30 minutes, when enabled.)
Thanks for clarifying. 30-60 minute window for announce packets. Still - we need to think about how we can capture the intermittent (mobile?) nodes that might connect once a day or who knows how infrequently.
@Nutomic Thanks for the Google Play and F-Droid numbers. Also, you mentioned earlier that the “Usage Reporting” dialog is missed in the Android app - unless the WebGUI is activated. However, the announce server gets the packets anyway, so I think we’re OK - if we can think of a method to capture these intermittent connections at the announce server.
The other source of hard data is the downloads from various sources. Pardon my ignorance, but are there any reliable methods to filter out new downloads vs. version upgrades?
Thanks.
Of course, the discovery server could keep track of this. But I’m not convinced we necessarily should, however harmless it might be. I’m kind of in the business of knowing as little as possible about what the users are doing, apart from what is being reported voluntarily…
Nope, downloads are downloads as far as Github is concerned. Of course, if we ran an upgrade server of our own we could know. As far as I understand the screenshot of the android store above, that would seem to be unique installs though.