Please note @starblessed this vote is not about the way to do it, but the whole WANT, do we want statistics.
@jasonrobinson - I know, and understand. Please don’t mistake my vote for being uninformed. My vote stands. I couldn’t fill out the complete answer as I had a character limit. I can’t now, because I am trying to sleep. Sufficed to say, I think the basic concept of what you are asking us to vote on is flawed. Being a distributed network, and what we stand for, gathering of statistics (opt in or not) goes against everything we have been striving to protect. At the end of the day, that’s what it boils down to. Privacy. If you can find a way of gathering COMPLETELY PRIVATE statistics (no urls; no direct info about the pods, including TOS) then sure, go for it. Until then, podupti.me is adequate enough.
“(main) point of the whole system - to gather metrics on the diaspora network.”
True. I did not see this anywhere in the proposal. I assumed (based on previous discussions here) that this was a proposed solution to the perceived problem of public post distribution. My bad.
“I just don’t see the point of building complicated things to make something simple”
Here’s where you missed my point 
What I proposed is simple. But then again, we’re aiming to solve two different problems, so they point is moot.
@starblessed of course you are entitled to disagree, I did not mean to indicate otherwise. I just find it odd that it is better to force podmins who want to list their pod in a directory to register with a commercial company (pingdom) to be enable to do that. Why is that good?
@rekado had to check the proposal, sure it’s a bit hidden, mainly because the proposal is too long, my bad.
While some technical proposals (like Relay servers for public posts and Tag aggregation) require or benefit from this kind of central hub, I think the real benefit is visibility into the network itself.
@jasonrobinson, may we please have longer to discuss, consider and vote on this issue? A week isn’t very long for a non-trivial issue. Hope that’s not a problem.
Alternatively, allow time for a discussion before opening the vote.
@goob sure, though I didn’t expect anyone to object to the possibility of acquiring metrics about the diaspora* network as a whole. I understand privacy, but how can a whole network have privacy as a whole? I just don’t get it, maybe I’ve understood diaspora* as a project wrongly since the beginning. I thought it was about building an alternative to things like Facebook Instead it seems that there is a strong sentiment towards being a non-network. Not quite sure why we need a foundation if we’re not going to be a network
This vote is mainly to clarify this. If there is strong support for the non-network side, personally I don’t see how I can help the project since I’m highly interested in building a network.
Oops sorry, I only skim-read the proposal and thought it was also about forming a centralised service - but you’ve said ‘regardless of the means of doing this’ - my mistake. Yes, I’m sure that will be a lot less controversial! Sorry.
Is it intended that every piece of information collected is optional? I realize that you’re wanting something to present to news media, but without nearly 100% opt-in (on every piece of information), this centralized stats service is nearly useless, because its information will be very inaccurate.
And yet, an opt-in without detailed control is not much of an opt-in. The important thing there is that once automated data-collection is authorized, how one keeps it from expanding to encompass information not contained in the original proposal. This is especially so given proposed centralized distribution points for public posts and hashtags. [“While some technical proposals (like Relay servers for public posts and Tag aggregation) require or benefit from this kind of central hub, I think the real benefit is visibility into the network itself.” https://wiki.diasporafoundation.org/Central_hub]
One of my early CS instructors said something that has always stuck with me:
All information that you collect will eventually be stored. All information that you store will eventually be misused.
I would rather support an optional page on each site which collected site-specific statistics (which could also be available in a machine-readable form), assuming that the podmin would have direct control over which stats were gathered and displayed .
I should note that there is at least one other federated network doing this already. The same issues could arise in the future there.
Would the collected statistics have any “marketable” value? We would never know how many accounts/users reported would be real ones. There can be any number of pods filled with bot accounts or pods reporting wrong data on purpose.
Hi Jason. Having information and statistics about is interesting. But as Jacob said, I don’t think we need a central entity to allow that. We could simply add a route like /statistics which will, if enabled in the config file, return a JSON containing anonymous statistics of the pod. Then, if we want to add a page “global statistics” which will do once per day a foreach on the pod table asking the stats of every pods, we can do that. We definitely don’t need a central entity to do that.
Actually, I could see this being potential for something along the lines of a more robust Pod Uptime. I wouldn’t be against having it integrated somewhere into the Diaspora Foundation project site. It could be useful for providing end users with a pod to go to, if they don’t want to self-host. We could probably integrate reviews and terms of service for different pods so that a user would have an easier time choosing where they would prefer to reside.
Finally someone agreeing with me - thank you @seantilleycommunit
I don’t understand who having a third party solution would benefit diaspora* network users better. Right now it’s actually a lot worse. I love these services but let me point something out.
diapod.net is opt-out, not opt-in. It will list your pod whether you want it to. AFAIK your pod could get listed even if you never make a single public post from it. How is that better than our own opt-in service?
podupti.me requires you to sign up to an account with pingdom which is commercial company. How is that better than our own service which doesn’t require setting up an account anywhere?
@flaburgan we need a pod list, period. The /statistics route is a great idea, the pod directory could poll that indeed.
Some other comments - Please don’t use the words decentralized and privacy, which are good words, to hide behind if you don’t even know what is being proposed. It’s ok to disagree (like Jonne and Rekado), just please don’t mix up technical details. I realize it was wrong to even bring this subject to the main group now. I think I’ll just start doing the hub part and then anyone who wants to join can patch their pod with the commits. In fact, I’ll close the vote as it’s clear there is just too much confusion being generated and I don’t feel like battling windmills.
@jonnehass btw, I did write clearly opt-in for the vote, please read more carefully.
@jasonrobinson don’t get me wrong, having a better list of the pods than poduti.me and maintained by the foundation is a good idea. My remark was on the approach you proposed: I’m not sure that hardcoding an url inside the config file is a good idea. I think we could simply have a boolean inside that file to say “I want to share statistics about my pod” or “i don’t want to share statistics”, and that’s it. After that, everybody who requests the correct url will have the information, so it could be used by poduti.me, by the other pods, by who we want. And we can propose to the podmins to register on diasporafoundation, as they do on poduti.me, and we will be able to list pods and their stats.
Since 2011 we do exactly this at https://diasp.eu/stats it would be nice if we can read the real amount of users for each pod instead of estimating it.
It’s funny, I was just about to write about the idea of decentralized stats - in my opinion every hub should have a page like that, showing main connected hubs’ statistics.
a big benefit is - we do not need to maintain hub’s codebase, and no need to host any additional service which is always a problem.
And none of the stats would tell the whole truth